Hallo Zusammen,
ich habe mein Thema jetzt mal in die Rubrik ASP gestellt, da ich gerade über so einer Anwendung sitze. Das Thema passt aber genau so auf Desktop-Anwendungen.
Ich stelle mir immer häufiger die Frage, ob es (noch) sinnvoll ist, Anwendungen in Client / Business und DataLayer zu unterteilen.
Warum stelle ich mir die Frage?
Bei nahezu jeder Anwendung reicht mein Businesslayer Entitäten nur vom Client zum Datalayer durch bzw. umgekehrt. Auch in Beispielanwendungen aus dem Netz passiert i.d.R. nichts anderes, als dass Entitäten weitergereicht werden.
Das Gegenteil sind Webanwendungen, in denen der komplette Businessteil bzw. auch der Datalayerteil in einer Webanwendung (einer Assembly) programmiert wird. Dies halte ich für weniger sinnvoll. Möchte man den Datalayer noch in einer Desktopanwendung verwenden, muss man den Code erst wieder mühselig trennen.
Von daher ist meine Frage, warum die normale Standardanwendung nicht lediglich in Client und Businesslayer unterteilt wird. Der Businesslayer wird bei mir i.d.R. mittels DependencyInjection in den Client gereicht. Der Businesslayer ist dann austauschbar, also für Mock oder Produktiv mit Speicherung der Daten z.B. im SQL-Server. Mein DbContext aus dem EntityFramework ist dann eben im Businesslayer und nicht im Datalayer enthalten. Es entfällt eine für mich unnötige Hierarchiestufe.
Mich würde von Euch interessieren, was hier gegen spricht. Die 3 Layer Architektur wird überall hervorgehoben. Warum ist das so?
Frank
ich habe mein Thema jetzt mal in die Rubrik ASP gestellt, da ich gerade über so einer Anwendung sitze. Das Thema passt aber genau so auf Desktop-Anwendungen.
Ich stelle mir immer häufiger die Frage, ob es (noch) sinnvoll ist, Anwendungen in Client / Business und DataLayer zu unterteilen.
Warum stelle ich mir die Frage?
Bei nahezu jeder Anwendung reicht mein Businesslayer Entitäten nur vom Client zum Datalayer durch bzw. umgekehrt. Auch in Beispielanwendungen aus dem Netz passiert i.d.R. nichts anderes, als dass Entitäten weitergereicht werden.
Das Gegenteil sind Webanwendungen, in denen der komplette Businessteil bzw. auch der Datalayerteil in einer Webanwendung (einer Assembly) programmiert wird. Dies halte ich für weniger sinnvoll. Möchte man den Datalayer noch in einer Desktopanwendung verwenden, muss man den Code erst wieder mühselig trennen.
Von daher ist meine Frage, warum die normale Standardanwendung nicht lediglich in Client und Businesslayer unterteilt wird. Der Businesslayer wird bei mir i.d.R. mittels DependencyInjection in den Client gereicht. Der Businesslayer ist dann austauschbar, also für Mock oder Produktiv mit Speicherung der Daten z.B. im SQL-Server. Mein DbContext aus dem EntityFramework ist dann eben im Businesslayer und nicht im Datalayer enthalten. Es entfällt eine für mich unnötige Hierarchiestufe.
Mich würde von Euch interessieren, was hier gegen spricht. Die 3 Layer Architektur wird überall hervorgehoben. Warum ist das so?
Frank
Comment