Kleine Anpassung: Die API Kommunikation läuft nicht über den Data-Access Layer sondern über einen Service oder API Layer, habe für das Beispiel den Layer also falsch benannt (shame on me). In den Data-Access Layer gehört vor allem der Zugriff zur Datenbank. Habe es im Skript falsch notiert da ich erst ein Beispiel mit einer SQL DB bringen wollte 😀 Egal, das Video macht trotzdem klar, wie man Anwendungen aufteilen sollte 🚀
Konzept ist klar. Die Frage die ich dabei habe ist: "Was macht diese Aufteilung besser als beispielsweise eine MVVM- Struktur?" Oder sollte man hier dann direkt Model, View und Viewmodel in separate Projekte packen? Was erreiche ich durch die Auftrennung in die verschiedenen Projekte für einen Benefit? Ernstgemeinte Frage :D Ich möchte meine Skills verbessern und verstehen, WARUM das so besser ist :D
@X0_BADWOLF Du vermischst hier zweierlei Konzepte. Die Auslagerung des API Services in eine separate Assembly war für das kleine Beispiel vielleicht bissl zu viel der Arbeit. Hätte auch die Ordnerstruktur um einen Ordner API erweitern können und dort den API Service reinpacken können. Dadurch das der API Service in einer Assembly ausgelagert wurde, kannst du ihn auch in anderen Projekten verwenden. Nehmen wir an, es geht um eine BusinessApplication im Bankenumfeld. Und an verschiedenen Stellen der Anwendung muss auf Personendaten zugegriffen werden. Anwendungen in diesem Umfeld sind sehr groß und oft auch von einender getrennt laufende WebServer Module. Damit kann sich der jeweilige Entwickler diese Assembly als dependency ins Projekt hinzufügen und aus der Datenbank lesen. Ein Interface IApiService hätte man noch drumbauen können, vereinfacht auch das Testen, da du dann eien MockAPIService übergeben könntest. Das Interface dann noch in eine separate Assemby und du gehst in Richtung composite components.
@@ponchobob Okay, das ergibt Sinn und das mache ich auch bereits. ^^ Dann habe ich das grundlegend wohl etwas falsch verstanden. Danke für die Klarstellung :)
@@X0_BADWOLF Wir haben auch Projekte ausgelagert. Ich komme zwar aus dem Webumfeld, aber bei uns sind das beispielsweise die Komponenten-library, eine eigene CMS Implementierung, etc. :)
dependencyInjection man ist flexibel z.B änderst Du Datenbank vom MySql Zu MSSQL musst Du nur den Interface(contract) implementieren . Ändert sich technologie (bessere) kannst Du nur interface implementieren bist elastisch lifecycle vom projekt ist länger
![WARNUNG: Mache NIE so eine Weiterbildung [Checkliste]](http://i.ytimg.com/vi/9o9SSRYnwrg/mqdefault.jpg)
Kleine Anpassung: Die API Kommunikation läuft nicht über den Data-Access Layer sondern über einen Service oder API Layer, habe für das Beispiel den Layer also falsch benannt (shame on me). In den Data-Access Layer gehört vor allem der Zugriff zur Datenbank. Habe es im Skript falsch notiert da ich erst ein Beispiel mit einer SQL DB bringen wollte 😀 Egal, das Video macht trotzdem klar, wie man Anwendungen aufteilen sollte 🚀
Konzept ist klar. Die Frage die ich dabei habe ist: "Was macht diese Aufteilung besser als beispielsweise eine MVVM- Struktur?" Oder sollte man hier dann direkt Model, View und Viewmodel in separate Projekte packen? Was erreiche ich durch die Auftrennung in die verschiedenen Projekte für einen Benefit? Ernstgemeinte Frage :D Ich möchte meine Skills verbessern und verstehen, WARUM das so besser ist :D
@X0_BADWOLF Du vermischst hier zweierlei Konzepte. Die Auslagerung des API Services in eine separate Assembly war für das kleine Beispiel vielleicht bissl zu viel der Arbeit. Hätte auch die Ordnerstruktur um einen Ordner API erweitern können und dort den API Service reinpacken können. Dadurch das der API Service in einer Assembly ausgelagert wurde, kannst du ihn auch in anderen Projekten verwenden. Nehmen wir an, es geht um eine BusinessApplication im Bankenumfeld. Und an verschiedenen Stellen der Anwendung muss auf Personendaten zugegriffen werden. Anwendungen in diesem Umfeld sind sehr groß und oft auch von einender getrennt laufende WebServer Module. Damit kann sich der jeweilige Entwickler diese Assembly als dependency ins Projekt hinzufügen und aus der Datenbank lesen. Ein Interface IApiService hätte man noch drumbauen können, vereinfacht auch das Testen, da du dann eien MockAPIService übergeben könntest. Das Interface dann noch in eine separate Assemby und du gehst in Richtung composite components.
@@ponchobob Okay, das ergibt Sinn und das mache ich auch bereits. ^^ Dann habe ich das grundlegend wohl etwas falsch verstanden. Danke für die Klarstellung :)
@@X0_BADWOLF Wir haben auch Projekte ausgelagert. Ich komme zwar aus dem Webumfeld, aber bei uns sind das beispielsweise die Komponenten-library, eine eigene CMS Implementierung, etc. :)
dependencyInjection man ist flexibel z.B änderst Du Datenbank vom MySql Zu MSSQL musst Du nur den Interface(contract) implementieren . Ändert sich technologie (bessere) kannst Du nur interface implementieren bist elastisch lifecycle vom projekt ist länger
sieht Ihr mein Kommentar?
Klar
@@CodingmitJannick Danke :)