finalize the documentation
This commit is contained in:
parent
9166b5196f
commit
d32326bfda
34
doku/bib.bib
34
doku/bib.bib
|
@ -1,7 +1,7 @@
|
|||
@misc{dbcs1,
|
||||
Day = {24},
|
||||
Month = {05},
|
||||
Note = {https://stackoverflow.com/questions/10740293/insert-an-insertion-date-value-into-a-sql-table-automatically},
|
||||
Note = {\url{https://stackoverflow.com/questions/10740293/insert-an-insertion-date-value-into-a-sql-table-automatically}},
|
||||
Urldate = {2017-07-24},
|
||||
author = {Wheat Mitch},
|
||||
title = {Insert an {``}insertion date{''} value into a SQL table automatically?},
|
||||
|
@ -12,7 +12,7 @@
|
|||
@misc{dbcs2,
|
||||
Day = {20},
|
||||
Month = {07},
|
||||
Note = {http://excel2latex.com/},
|
||||
Note = {\url{http://excel2latex.com/}},
|
||||
Urldate = {2017-07-24},
|
||||
author = {Wood Eric},
|
||||
title = {excel => LaTeX},
|
||||
|
@ -23,7 +23,7 @@
|
|||
@misc{dbcs3,
|
||||
Day = {26},
|
||||
Month = {07},
|
||||
Note = {https://tex.stackexchange.com/questions/133/how-can-i-make-a-table-that-takes-up-more-than-a-single-page},
|
||||
Note = {\url{https://tex.stackexchange.com/questions/133/how-can-i-make-a-table-that-takes-up-more-than-a-single-page}},
|
||||
Urldate = {2017-07-24},
|
||||
author = {Vanden},
|
||||
title = {How can I make a table that takes up more than a single page?},
|
||||
|
@ -32,7 +32,7 @@
|
|||
}
|
||||
|
||||
@misc{dbcs4,
|
||||
Note = {http://www.personal.ceu.hu/tex/footnote.htm},
|
||||
Note = {\url{http://www.personal.ceu.hu/tex/footnote.htm}},
|
||||
Urldate = {2017-07-24},
|
||||
author = {Central European University},
|
||||
title = {LaTeX Footnotes},
|
||||
|
@ -43,7 +43,7 @@
|
|||
@misc{dbcs5,
|
||||
Day = {28},
|
||||
Month = {02},
|
||||
Note = {https://iamtimcorey.com/csharp-sql-data-access/},
|
||||
Note = {\url{https://iamtimcorey.com/csharp-sql-data-access/}},
|
||||
author = {Tim Corey},
|
||||
title = {C\# Data Access: SQL Database},
|
||||
year = {2017},
|
||||
|
@ -53,9 +53,29 @@
|
|||
@misc{dbcs6,
|
||||
Day = {20},
|
||||
Month = {07},
|
||||
Note = {https://github.com/StackExchange/Dapper},
|
||||
Note = {\url{https://github.com/StackExchange/Dapper}},
|
||||
author = {StackExchange},
|
||||
title = {Dapper - a simple object mapper for .Net},
|
||||
year = {2017},
|
||||
tags = "db_case-study"
|
||||
}
|
||||
}
|
||||
|
||||
@misc{dbcs7,
|
||||
Day = {{27}},
|
||||
month = {{08}},
|
||||
note = {\url{{https://de.wikipedia.org/wiki/Anwendungsfalldiagramm}}},
|
||||
author = {Wikipedia},
|
||||
title = {{Anwendungsfalldiagramm {--} Wikipedia}},
|
||||
year = {2017},
|
||||
tags = "db_case-study"
|
||||
}
|
||||
|
||||
@misc{dbcs8,
|
||||
Day = {{27}},
|
||||
month = {{08}},
|
||||
note = {\url{{https://de.wikipedia.org/wiki/Anwendungsfall}}},
|
||||
author = {Wikipedia},
|
||||
title = {{Anwendungsfall {--} Wikipedia}},
|
||||
year = {2017},
|
||||
tags = "db_case-study"
|
||||
}
|
||||
|
|
235
doku/content.tex
235
doku/content.tex
|
@ -16,7 +16,7 @@ Folgende Stakeholder sind in diesem Projekt zu berücksichtigen:
|
|||
\item Marktbesucher
|
||||
\end{itemize}
|
||||
|
||||
Diagramm (\ref{fig:stakeholder}) zeigt die Beziehung der Stakeholder
|
||||
Abbildung: (\ref{fig:stakeholder}) zeigt die Beziehung der Stakeholder
|
||||
zum Projekt noch grafisch auf.
|
||||
|
||||
\begin{figure}
|
||||
|
@ -67,6 +67,11 @@ werden.
|
|||
|
||||
\newpage
|
||||
\section{User Stories}
|
||||
User Stories sind sind eine in Alltagsprache geschriebenen
|
||||
Software-Anforderungen. Sie sind bewusst kurz gehalten und
|
||||
beschreiben die Wünsche und Ziele der Rollen welche die
|
||||
Software verwenden.
|
||||
|
||||
\subsection{Verwaltung}
|
||||
Als Plattforminhaber möchte ich,
|
||||
\begin{itemize}
|
||||
|
@ -107,14 +112,76 @@ Als Marktbesucher möchte ich,
|
|||
|
||||
\newpage
|
||||
\section{Use Cases}
|
||||
Ein Use Case sammelt alle möglichen Szenarien, die eintreten können,
|
||||
wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein
|
||||
bestimmtes Ziel zu erreichen. Dabei beschreibt er was beim Versuch der
|
||||
Zielerreichung passieren kann. Je nach Ablauf kann auch ein Fehlschlag
|
||||
ein Ergebnis eines Anwendungsfalls sein (e.g. falsches Passwort beim
|
||||
Login). Dabei wird die technische Lösung nicht konkret beschrieben.
|
||||
Die Detailstufe kann dabei sehr unterschiedlich sein.
|
||||
|
||||
\subsection{Use Case Diagramm}
|
||||
``Ein Anwendungsfalldiagramm ... ist eine der 14 Diagrammarten der
|
||||
Unified Modeling Language (UML), einer Sprache für die Modellierung
|
||||
der Strukturen und des Verhaltens von Software- und anderen Systemen.
|
||||
Es stellt Anwendungsfälle und Akteure mit ihren jeweiligen
|
||||
Abhängigkeiten und Beziehungen dar.''\cite{dbcs7}
|
||||
|
||||
\subsection{Use Cases}
|
||||
Wir verschaften uns dabei mit einem Use Case Diagramm, zu sehen in
|
||||
Abbildung: (\ref{fig:use_case}), zuerst einen groben Überblick über
|
||||
die Use Cases und wie sie zusammenhängen.
|
||||
|
||||
\subsection{Use Cases Detailbeschreibungen}
|
||||
Für die Ausarbeitung der C\# Applikation haben wir uns für 5 Use Cases
|
||||
entschieden und diese in einer Use Case Schablone von Alistair
|
||||
Cockburn im Detail ausgearbeitet und beschrieben haben. Die Alistair
|
||||
Cockburn Schablone gibt eine gute Vorgabe für den Inhalt der Use Case
|
||||
Beschreibung.
|
||||
|
||||
\subsubsection{Lösungsvarianten}
|
||||
|
||||
Wir wollen hier auch noch darauf eingehen welche Varianten wir uns
|
||||
überlegt haben und wieso wir uns am Ende für die nachfolgenden 5 Use
|
||||
Cases entschieden haben. Dabei war es uns besonders wichtig das bei
|
||||
den Use Cases, Daten aus der Datenbank ausgelesen sowie auch
|
||||
geschreiben werden müssen.
|
||||
|
||||
Wir haben uns dabei zu Beginn die folgenden drei möglichen Szenarien
|
||||
überlegt:
|
||||
\begin{itemize}
|
||||
\item Login und Registrierung einer Person.
|
||||
\item Lösen eines Abonnements.
|
||||
\item Mieten eines Standorts.
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Login und Registrierung einer Person.}
|
||||
|
||||
Bei dieser Lösungsvariante würde der komplette Registrierungsprozess
|
||||
abgebildet werden. Dabei würden auch die Adressdaten etc. der Person
|
||||
erfasst werden.
|
||||
\paragraph{Lösen eines Abonnements.}
|
||||
|
||||
Das Lösen eines Abonnements würde behinhalten das eine bestehende
|
||||
Person eines der verschiedenen Abonnemente anschauen, auswählen und
|
||||
anschliessend ``kaufen'' könnte.
|
||||
|
||||
\paragraph{Mieten eines Standorts.}
|
||||
|
||||
Beim Mieten eines Standortes könnte ein Mitglied die Marktstandorte
|
||||
einsehen, auswählen und sich dort einen Spot reservieren.
|
||||
|
||||
\paragraph{Gewählte Variante}
|
||||
|
||||
Schlussendlich haben wir uns dafür entschieden einen Login und die
|
||||
Registrierung umzusetzen. Allerdings haben wir beschlossen das wir uns
|
||||
darauf beschränken ein Mitglied nur mit einer Email Adresse und einem
|
||||
Passwort zu erfassen. Zusätzlich schien uns das Mieten eines Standorts
|
||||
noch eine gute Funktion um eine Teilfunktion der Applikation
|
||||
abzubilden.
|
||||
|
||||
\begin{landscape}
|
||||
|
||||
\begin{figure}[H]
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[height=0.9\textheight]{diagrammes/use_cases.png}
|
||||
\caption{Use Case Diagramm\label{fig:use_case}}
|
||||
|
@ -393,18 +460,50 @@ Haben die Länder und Städte Listen bereits komplett zu erstellen. \\ \hline
|
|||
|
||||
\section{Umsetzung}
|
||||
|
||||
\subsection{Lösungsvarianten}
|
||||
|
||||
\subsection{Zusammenarbeit}
|
||||
Zur Zusammenarbeit am Code haben wir uns für Git entschieden. Dies
|
||||
ermöglichte es uns gleichzeitig am Code zu arbeiten und zwischendurch
|
||||
die Änderungen des anderen zu ``mergen''. Dies war von grossem Vorteil
|
||||
da wir so unabhängig voneinander am Code weiterarbeiten konnten. So
|
||||
entstanden insgesammt über 150 Commits.
|
||||
|
||||
\subsection{ERM}
|
||||
Desweiteren haben wir uns die Arbeit so aufgeteilt damit wir möglichst
|
||||
unabhängig voneinander arbeiten konnten und somit nicht aufeinander
|
||||
warten mussten.
|
||||
|
||||
\subsection{RM/SQL}
|
||||
Andreas hat sich Hauptsächlich mit den SQL Scripts beschäftigt.
|
||||
Parallel dazu konnte sich Ismail in das Schreiben einer grafischen C\#
|
||||
Applikation einlesen. Sobald die SQL Skripte fertig waren konnte
|
||||
Ismail diese nutzen um die Applikation fertig zu stellen.
|
||||
|
||||
Die Dokumentation wurde dabei fortlaufen erweitert. Da wir die
|
||||
Dokumentation in \LaTeX geschrieben haben und somit auch nur aus
|
||||
simplen Textdateien besteht konnten wir auch an dieser ohne Probleme
|
||||
gleichzeitig arbeiten und über Git versionieren.
|
||||
|
||||
\subsection{ER Modell und ER Diagramm}
|
||||
Gleich zu Beginn des Projektes haben wir den Text zur Aufgabenstellung
|
||||
eingehend analysiert und daraus ein Entity-Relationship-Modell(ERM),
|
||||
Abbildung: (\ref{fig:rm}) erstellt.
|
||||
|
||||
Wir haben dabei darauf verzichtet für jede Entität noch die jeweiligen
|
||||
Attribute einzuzeichnen da wir uns mit dem ERM Hauptsächlich einen
|
||||
Überblick über die Situation verschaffen wollten damit wir die
|
||||
Abhängigkeiten zwischen den Entitäten besser nachvollziehen konnten.
|
||||
|
||||
Im Anschluss wurden dann das Entity-Relationship-Diagramm(ERD),
|
||||
Abbildung: (\ref{fig:erm}) erstellt. Dies wurde mit allen Details
|
||||
erstellt. Im ERD haben wir auch Eigenschaften von Attributen erfasst
|
||||
welche in der exportieren Übersicht hier in der Dokumentation nicht
|
||||
ersichtlich sind, wie etwa ``Unique'', ``Not Null'', etc. Aus dem ERD
|
||||
konnten dann relativ schnell die SQL Scripts abgeleitet werden.
|
||||
|
||||
\subsection{SQL Datenbank}
|
||||
|
||||
Nachfolgend werden die Entitäten der Datenbank kurz beschrieben damit
|
||||
das ERM Diagramm (\ref{fig:erm}) besser verstanden werden kann. Dabei
|
||||
wird zuerst der Name der Tabelle in der Datenbank aufgelistet gefolgt von der
|
||||
deutschen Übersetzung.
|
||||
das ERD Diagramm, Abbildung: (\ref{fig:erm}) besser verstanden werden
|
||||
kann. Dabei wird zuerst der Name der Tabelle in der Datenbank
|
||||
aufgelistet gefolgt von der deutschen Übersetzung.
|
||||
|
||||
\paragraph{persons / (Personen)}
|
||||
Sind die Repräsentation einer realen Person in der Datenbank. Hier
|
||||
|
@ -487,7 +586,7 @@ Interessengruppen anzupassen.
|
|||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[height=0.8\textheight]{diagrammes/rm.png}
|
||||
\caption{ERM Diagramm\label{fig:rm}}
|
||||
\caption{Entity-Relationship-Modell\label{fig:rm}}
|
||||
\end{figure}
|
||||
\end{landscape}
|
||||
|
||||
|
@ -496,7 +595,7 @@ Interessengruppen anzupassen.
|
|||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[scale=0.38]{diagrammes/erm.png}
|
||||
\caption{RM Diagramm\label{fig:erm}}
|
||||
\caption{Entity-Relationship-Diagramm\label{fig:erm}}
|
||||
\end{figure}
|
||||
\end{landscape}
|
||||
|
||||
|
@ -531,7 +630,7 @@ Hier werden alle eingesetzten Klassen der Applikation vorgestellt
|
|||
und definiert.
|
||||
|
||||
Zu jeder Klasse gibt es eine passende Grafik welche ihre Methoden und
|
||||
Attribute beschreibt. Nachfolgend habe wir eine Beispiel Grafik
|
||||
Attribute beschreibt. Nachfolgend habe wir eine Beispiel Grafik, Abbildung:
|
||||
(\ref{fig:class_example}) eingefügt welche die Symbole und den Aufbau
|
||||
beschreibt.
|
||||
|
||||
|
@ -554,53 +653,73 @@ definiert werden und kann dann durch die Helper.cs Klasse simpel
|
|||
aufgerufen werden.
|
||||
|
||||
\paragraph{LoginForm}
|
||||
Diese Klasse wurde für das Registrieren und Einloggen des Benutzers
|
||||
mit einem dazugehörigen GUI von uns erstellt. Dadurch können sich
|
||||
Diese Klasse, Abbildung: (\ref{fig:login_class}) wurde für das
|
||||
Registrieren und Einloggen des Benutzers mit einem dazugehörigen GUI,
|
||||
Abbildung: (\ref{fig:login}), von uns erstellt. Dadurch können sich
|
||||
Benutzer durch das Eingeben der Email-Adresse und des Passwortes mit
|
||||
dem ``Register-Button'' Registrieren und durch ein zweites eingeben der
|
||||
Daten und betätigen des ``Login-Button'' auch gleich einloggen. Nach dem
|
||||
Login wird auch gleich eine Nachricht der Applikation dem Benutzer mit
|
||||
dem Text ``It worked'' aufgezeigt, um den erfolgreichen Login zu melden.
|
||||
Dadurch möchten wir die Funktion des Einfüllens und Lesen der Daten aus
|
||||
der Datenbank aufzeigen.
|
||||
dem ``Register-Button'' Registrieren und durch ein zweites eingeben
|
||||
der Daten und betätigen des ``Login-Button'' auch gleich einloggen.
|
||||
Nach dem Login wird auch gleich eine Nachricht der Applikation dem
|
||||
Benutzer mit dem Text ``It worked'' aufgezeigt, um den erfolgreichen
|
||||
Login zu melden. Dadurch möchten wir die Funktion des Einfüllens und
|
||||
Lesen der Daten aus der Datenbank aufzeigen.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{diagrammes/loginform.png}
|
||||
\caption{LoginForm Klasse}
|
||||
\label{fig:login_class}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\frame{\includegraphics[scale=0.7]{screenshots/login.png}}
|
||||
\caption{Screenshot der LoginForm}
|
||||
\label{fig:login}
|
||||
\end{figure}
|
||||
|
||||
\paragraph{Dashboard}
|
||||
Auf dem Dashboard haben wir den Kern was Informationen herauslesen und
|
||||
wieder Eingeben belangt, erstellt. In dieser Klasse werden die aus der
|
||||
Datenbank herausgelesenen Daten der ``locations'' und ``rents''
|
||||
Tabellen im GUI aufgezeigt und /oder eingefügt. Damit möchten wir
|
||||
einen Teil der finalen Applikation und Datenbank abbilden mit dem, die
|
||||
Benutzer Standorte heraussuchen und den Mietbeginn eingegeben können.
|
||||
Um unsere Demo-Applikation simpel zu halten, kann ein Mitglied nach
|
||||
dem Registrieren und Einloggen die vom Verwalter hinzugefügten
|
||||
Standorte heraussuchen, sie dann in unsere Mietbox schieben und nach
|
||||
dem wählen des gewünschten Zeitpunktes den Standort mieten.
|
||||
Auf dem Dashboard, Abbildung: (\ref{fig:dashboard_class}), haben wir
|
||||
den Kern was Informationen herauslesen und wieder Eingeben belangt,
|
||||
erstellt. In dieser Klasse werden die aus der Datenbank
|
||||
herausgelesenen Daten der ``locations'' und ``rents'' Tabellen im GUI,
|
||||
Abbildung: (\ref{fig:dashboard}) aufgezeigt und /oder eingefügt. Damit
|
||||
möchten wir einen Teil der finalen Applikation und Datenbank abbilden
|
||||
mit dem, die Benutzer Standorte heraussuchen und den Mietbeginn
|
||||
eingegeben können. Um unsere Demo-Applikation simpel zu halten, kann
|
||||
ein Mitglied nach dem Registrieren und Einloggen die vom Verwalter
|
||||
hinzugefügten Standorte heraussuchen, sie dann in unsere Mietbox
|
||||
schieben und nach dem wählen des gewünschten Zeitpunktes den Standort
|
||||
mieten.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{diagrammes/dashboard.png}
|
||||
\caption{Dashboard Klasse}
|
||||
\label{fig:dashboard_class}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\frame{\includegraphics[width=0.9\textwidth]{screenshots/dashboard.png}}
|
||||
\caption{Screenshot des Dashboards}
|
||||
\label{fig:dashboard}
|
||||
\end{figure}
|
||||
|
||||
\paragraph{DataAccess}
|
||||
Mit der DataAccess Klasse konnten wir nahezu alle Datenbank relevanten
|
||||
Funktionen, die in unserem GUI ausgeführt werden, in einer einzigen
|
||||
Klasse abbilden. Darin haben wir den Aufruf der Datenbanktabellen mit
|
||||
den dazu benötigten SQL - Befehlen ausgeführt. Dadurch wird SQL- Code
|
||||
so gut wie nur in dieser Klasse aufgerufen und diesbezüglich
|
||||
verwendet. Unter anderem wird auch der Login des Benutzers darin
|
||||
geprüft.
|
||||
Mit der DataAccess Klasse, Abbildung: (\ref{fig:dataaccess}) konnten wir
|
||||
nahezu alle Datenbank relevanten Funktionen, die in unserem GUI
|
||||
ausgeführt werden, in einer einzigen Klasse abbilden. Darin haben wir
|
||||
den Aufruf der Datenbanktabellen mit den dazu benötigten SQL -
|
||||
Befehlen ausgeführt. Dadurch wird SQL- Code so gut wie nur in dieser
|
||||
Klasse aufgerufen und diesbezüglich verwendet. Unter anderem wird auch
|
||||
der Login des Benutzers darin geprüft.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{diagrammes/dataaccess.png}
|
||||
\caption{DataAccess Klasse}
|
||||
\label{fig:dataaccess}
|
||||
\end{figure}
|
||||
|
||||
\paragraph{Get-``Klassen''}
|
||||
|
@ -611,33 +730,38 @@ sie abbilden. Damit nehmen die dazu benötigten Spalten der jeweiligen
|
|||
Tabellen entgegen. Danach werden die benötigten Datensätze mit den
|
||||
``Methoden-Infos'' der derweiligen Klasse aufgerufen.
|
||||
|
||||
Die ``GetMembers'' Klassen wird für die Registration und den Login der
|
||||
Mitglieder benötigt:
|
||||
Die ``GetMembers'' Klasse, Abbildung: (\ref{fig:getmembers}), wird für
|
||||
die Registration und den Login der Mitglieder benötigt:
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{diagrammes/getmembers.png}
|
||||
\caption{GetMembers Klasse}
|
||||
\label{fig:getmembers}
|
||||
\end{figure}
|
||||
|
||||
Die ``GetRents'' Klasse für`s Mieten und Abbilden der jeweiligen Märkte:
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{diagrammes/getrents.png}
|
||||
\caption{GetRents Klasse}
|
||||
\end{figure}
|
||||
|
||||
Die ``GetLocations'' Klasse für das Herauslesen der Märkte um dem Mitglied alle
|
||||
im Moment hinzugefügten Mietoptionen darzubieten:
|
||||
Die ``GetLocations'' Klasse, Abbildung: (\ref{fig:getlocations}), für
|
||||
das Herauslesen der Märkte um dem Mitglied alle im Moment
|
||||
hinzugefügten Mietoptionen darzubieten:
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{diagrammes/getlocations.png}
|
||||
\caption{GetLocations Klasse}
|
||||
\label{fig:getlocations}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Problematik}
|
||||
Die ``GetRents'' Klasse, Abbildung: (\ref{fig:getrents}), für`s Mieten
|
||||
und Abbilden der jeweiligen Märkte:
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[scale=0.7]{diagrammes/getrents.png}
|
||||
\caption{GetRents Klasse}
|
||||
\label{fig:getrents}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Probleme}
|
||||
|
||||
\begin{itemize}
|
||||
\item Verbindungsaufbau
|
||||
|
@ -646,13 +770,13 @@ im Moment hinzugefügten Mietoptionen darzubieten:
|
|||
|
||||
\item Insert Data
|
||||
Nach den ersten Test's wurde uns klar, dass wir ein Problem mit
|
||||
den jeweiligen ID's hatten. Der Fehler kam erst ans Licht, als wir
|
||||
anfingen die jeweiligen ''locations und ''members''- ID's durch das
|
||||
GUI einzufügen.
|
||||
der weitergabe der ID's hatten. Der Fehler kam erst ans Licht, als wir
|
||||
anfingen die jeweiligen ``locations'' und ``members''- ID's durch das
|
||||
GUI einzufügen. Gelöst wurde das ganze mit einer statischen Klasse.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Referenzen und Addons/ Packages}
|
||||
\subsubsection{Addons/ Packages}
|
||||
Dapper \cite{dbcs6} ist ein simpler ``object mapper'' für .NET. Wir
|
||||
nutzen ihn anstelle von einem ADO.NET data reader da er nütziche
|
||||
Erweiterungen bei unserer IDbConnection bietet, indem er
|
||||
|
@ -670,7 +794,6 @@ Dapper erweitert unsere IDbConnection verwendung mit mehreren Methoden wie :
|
|||
\end{itemize}
|
||||
Weiter Infos unter : http://dapper-tutorial.net/dapper
|
||||
|
||||
|
||||
\newpage
|
||||
\begin{landscape}
|
||||
\section{Testfälle}
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 10 KiB |
Binary file not shown.
After Width: | Height: | Size: 1.8 KiB |
Loading…
Reference in New Issue