Hi NG,
ich soll eine Anwendung in C# für eine Projektsoftware realisieren und habe
mir eine 4 Schichten Architektur vorgestellt.
1) Einen Database Layer der auf SQL Datenbanken, XML Files, etc.
schreibt/liest
2) Einen Data Access Layer, der von dem darunter liegenden Database Layer
abstrahiert und generische CRUD Methode bereitstellt
3) Einen Business Logic Layer in dem die Anwendungslogik sitz
4) Einen Presentation Layer zB mit Windows Forms


-----------------------------------------
Presentation Layer
-----------------------------------------
Business Logic
-----------------------------------------
Data Access Layer
-----------------------------------------
SQL Layer | File Layer | Cloud Layer
-----------------------------------------


Während der Entwicklung bin ich nun in folgenden Gewissenskonflik gekommen:

Der Data Access Layer hat eine abstrakte Superklasse DAL mit einer Methode
CreateProject und u.a. eine Klassen DALSql die von DAL erbt und die
notwendigen Methoden im SQL Database Layer (Linq Zeugs) aufruft um ein
Projekt zu erstellen. Das bedeutet auch dass es eine "Struktur" Projekt im
Data Access Layer gibt.

public class DALSql : DAL
{
public override Project CreateProject(string name)
{
// ... Linq Klassen , db.SubmitChanges() etc.
}

public override Project ReadProject(int projectId)
{
// .. Linq Zeugs, Select ... etc.
}
}

Aber andererseits ist "Projekt" ein Objekt aus der Fachdomäne, und sollte im
Business Layer sitzen. Wenn ich jetzt im Presentation Layer ein Projekt
anzeige muss ich natürlich den Business Layer verwenden (Berechnungen, usw),
aber auch den darunter liegenden Layer verwenden um überhaupt ein "Projekt"
Objekt zu haben. IMHO sollte das nicht sein, weil Layer Konzept *kopfschmerz*

"Projekt" etc. kann ich aber nicht ohne weiteres auf den Business Layer
hochziehen, weil ich sie ja im Data Access Layer brauche. Also bliebe mir nix
anderes übrig als die Klassen quasi zu duplizieren. Ein BusinessLayer.Projekt
und ein DataAccessLayer.Projekt . Zu allem Unglück habe ich auch noch eine
Linq2SQL Klassen Project.


Wie ich es drehe und wende, es wird nicht schöner. Hat jemand eine Idee ?

--
My LinkedIn Profile:
http://www.linkedin.com/in/noebauer
Xing:
https://www.xing.com/profile/Markus_Noebauer

Hallo Markus,

> ich soll eine Anwendung in C# für eine Projektsoftware realisieren
> und habe mir eine 4 Schichten Architektur vorgestellt.

Das entscheidende ist ja im Prinzip nicht, wie Du es gerade siehst,
sondern welche *Anforderungen* an Deine Software, Dein
Projekt gestellt sind. Nur könnte ich Dir einen Rat geben, ob
das so sinnvoll ist. Mit dem (eng gekoppelten) "Linq To Sql"
ist bspw. die Schichtung deutlich schwieriger als etwa mit dem
Entity Framework. Ganz klar der Rat da: nimm in Enterprise
n-tier Szenarien das Entity Framework. Fast schon in Betracht
ziehen, die VS 2010 Beta 2 bei neuen Projekten zu benutzen,
die bzgl. des EF 4 nochmals drauflegt.

[Video : LINQ-to-SQL versus ADO.NET Entity Framework]
http://www.microsoft.com/germany/msd...=msdn_de_30124
(eine der zahlreichen Vergleiche von EF und LTS)

Du hast auch normal selten reine horizontale Schichten Ã* la OSI
Modell o.ä., sondern immer auch "gemeinsame Komponenten",
die von allen zugreifbar sind (also vertikal).

Beim ganzen ist folgendes als Hintergrundlektüre sehr empfehlenswert:

[Microsoft Application Architecture Guide, 2nd Edition]
http://msdn.microsoft.com/en-us/library/dd673617.aspx

Weil die Presentation Layer bei Dir ja auch noch offen
sein soll/ist, sind auch die pragmatischen Ansätze
unbedingt zu beachten, (deswegen... Anforderungen wichtig) :

[MSDN Webcast Serie: Pragmatische Web-Architektur]
http://www.microsoft.com/germany/msd...S-0604-02.mspx

[Neue MSDN Webcast-Serie zu ASP.NET Architektur | PGK GmbH]
http://www.pgk.de/news/2009-06-24_pwa.aspx


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Hallo Markus,

> "Projekt" etc. kann ich aber nicht ohne weiteres auf den Business Layer
> hochziehen, weil ich sie ja im Data Access Layer brauche.

eine solche Architektur realisiert man eigentlich bei allen mir
bekannten Persistenzframeworks so: deine Klasse "Projekt" existiert nur
im Business Layer. Sie sollte nun hinreichend viele Metadaten
bereitstellen, dass der "Data Access Layer" alle erforderlichen
SQLs/Datenzugriffsanweisungen etc. generieren kann, ohne selber eine
Klasse "Projekt" zu beinhalten. Je nach Framework liegen die Metadaten
unterschiedlich vor (z.B. als separate XML-Dateien, als über Reflection
auszuwertende Attribute o.ä.), und werden zu unterschiedlichen
Zeitpunkten (Erstellungszeitpunkt, Ausführungszeitpunkt) ausgewertet.

Für welches Framework du dich entscheidest, oder ob du alles "von Hand"
machen willst, hängt letztendlich von deinen Anforderungen, den
Rahmenbedingungen und der Größe deiner Software ab (sagte Frank ja auch
schon). Kriterien sind z.B. welche Datenbank(en) willst du unterstützen,
hast du ein vorgegebenes relationales Datenmodell oder hast du die
Modellierung komplett in der Hand, wie komplex ist dein Datenmodell, was
hast an Tools/Bibliotheken etc. zur Verfügung, was darf es kosten, wie
sind die Performance / Speicheranforderungen, wie groß ist das Team (je
größer, desto wichtiger ist es, ein gut dokumentiertes Standardprodukt
einzusetzen), musst du noch Windows 2000 unterstützen (falls ja,
könntest du nur .NET 2.0 einsetzen) usw.

Grüße

- Michael -

Michael v. Fondern wrote:

> eine solche Architektur realisiert man eigentlich bei allen mir
> bekannten Persistenzframeworks so: deine Klasse "Projekt" existiert nur
> im Business Layer. Sie sollte nun hinreichend viele Metadaten
> bereitstellen, dass der "Data Access Layer" alle erforderlichen
> SQLs/Datenzugriffsanweisungen etc. generieren kann, ohne selber eine
> Klasse "Projekt" zu beinhalten.

Wie geht das zum Beispiel beim Entity Framework? Die automatisch aus der
Tabellenstruktur generierten Klassen enthalten keine Geschäftslogik. Um
diesem 'Skelett' dann etwas Leben zugeben, können die generierten
Klassen des Persistenzlayers auf ihre Gegenparts im Business Layer
gemappt werden, z.B. über LINQ.

Sollte man in einem "ernsthaften" Projekt also die Schichten so weit
entkoppeln, oder wird in der Praxis zur Vereinfachung angestrebt, die
Objekte des Datenlayers auch als Domänenobjekte zu benutzen?

Im EF 4.0 ändert sich hier einiges, aber wie wurde dies bisher gelöst?

Viele Grüße,
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphiâ„¢ and for the Javaâ„¢ platform
http://www.mikejustin.com - http://www.betabeans.de

Hallo Michael,
> Wie geht das zum Beispiel beim Entity Framework? Die automatisch aus der
> Tabellenstruktur generierten Klassen enthalten keine Geschäftslogik. Um
> diesem 'Skelett' dann etwas Leben zugeben, können die generierten
> Klassen des Persistenzlayers auf ihre Gegenparts im Business Layer
> gemappt werden, z.B. über LINQ.

Das ist sicher anders gedacht. Die automatisch aus der
Tabellenstruktur generierten Klassen gehören bereits zum Business Layer,
und nicht zum Data Access Layer. Sie enthalten insofern schon (wenn man
das mal so nennen will: statische) Geschäftslogik, als dass sie Namen
für die "Objekte des Geschäfts" und deren Attribute und Beziehungen
untereinander festlegen. Diese Klassen sind zudem "partial", d.h.
"echte" Geschäftslogik lässt sich ihnen direkt hinzufügen, weitere
"Gegenparts", wie du sie nennst, werden nicht gebraucht. "LINQ to
Entities" stellt dabei den "Data Access Layer" dar - den braucht man
selber nicht mehr zu bauen.

> Sollte man in einem "ernsthaften" Projekt also die Schichten so weit
> entkoppeln, oder wird in der Praxis zur Vereinfachung angestrebt, die
> Objekte des Datenlayers auch als Domänenobjekte zu benutzen?

Ernsthafte Projekte sollten immer das "DRY"-Prinzip ("Don't repeat
yourself") befolgen. Zu jeder Business-Klasse eine korrespondierende
zweite Klasse im Data Access Layer zu bauen verletzt dieses Prinzip und
führt nicht gerade zu verbesserter Wartbarkeit / Weiterentwickelbarkeit
("Evolvierbarkeit") des Codes.

> Im EF 4.0 ändert sich hier einiges, aber wie wurde dies bisher gelöst?

Das die Klassen "partial" sind ist (glaub ich) nicht erst im EF 4.0 so.

Vielleicht schaust du dir mal den Vortrag von Holger Schwichtenberg an,
auf den Frank hier schon verlinkt hatte, da findest du mehr Infos.

Grüße

- Michael -

kleine Korrektur:
> "LINQ to Entities" stellt dabei den "Data Access Layer" dar ..

stimmt natürlich so nicht ganz, sondern der "Data Access Layer" ist der
Teil des Entity Frameworks, der für die Persistenz sorgt.

Grüße

- Michael -

Hallo Zusammen,
> -----------------------------------------
> Presentation Layer
> -----------------------------------------
> Business Logic
> -----------------------------------------
> Data Access Layer
> -----------------------------------------
> SQL Layer | File Layer | Cloud Layer
> -----------------------------------------
sehr interessantes Thema.
http://www.pgk.de/news/2009-06-24_pwa.aspx

Jedoch anspruchsvoll.
Für mich schwierig das Thema Factory zu verstehen.
Teil 1 war noch ok.
Bei Teil 2 hatte ich schon Schwierigkeiten.

Ist diese Schichtenarchitektur eigentlich gängig?

Frage an die Gruppe.
Gibt es noch andere Beispiele, um es zu verdeutlichen?
http://de.wikipedia.org/wiki/Softwarearchitektur

Was haltet Ihr von diesen Büchern?
http://www.amazon.de/C-3-0-Entwurfsm...7704093&sr=1-1

http://www.amazon.de/C-von-Kopf-bis-...ef=pd_sim_b_16

http://www.buchspektrum.de/bestellen...sbn=3772364101

Grüße Markus

Hallo Markus,
> Ist diese Schichtenarchitektur eigentlich gängig?

wenn du die meinst, die der O.P. genannt hatte: ja. Wie lange schon? Ich
schätze mal, diese Form des Schichtenmodells dürfte so Anfang bis Mitte
der 90er aufgekommen sein.

> Frage an die Gruppe.
> Gibt es noch andere Beispiele, um es zu verdeutlichen?
> http://de.wikipedia.org/wiki/Softwarearchitektur

Der englische Artikel ist deutlich besser:

http://en.wikipedia.org/wiki/Software_architecture

Ansonsten ist das Web voll davon, such mal nach "Schichtenmodell",
"Three tier architecture", "Mehrschichtige Architektur" o.ä.

Grüße

- Michael -

Hallo Michael,

> Der englische Artikel ist deutlich besser:
>
> http://en.wikipedia.org/wiki/Software_architecture
Deutsch ist für schwierige Themen halt noch etwas besser.
>
> Ansonsten ist das Web voll davon, such mal nach "Schichtenmodell", "Three
> tier architecture", "Mehrschichtige Architektur" o.ä.
ok. Danke.
Dennoch kannst Du gute Bücher in Zusammenhang mit C# empfehlen?
Evtl. kleinere Applikationen. Der WebCast von Patrick mag schon gut sein.
Er nimmt auch viel fertiges.
Kurse von Microsoft sind für Privatpersonen nicht bezahlbar.

Grüße

- Markus -

Hallo Markus,
>> Der englische Artikel ist deutlich besser:
>>
>> http://en.wikipedia.org/wiki/Software_architecture
> Deutsch ist für schwierige Themen halt noch etwas besser.

Wenn's inhaltlich auch nur annäherungsweise an den englischen Artikel,
rankäme, vielleicht schon. De facto in diesem Fall aber sicher nicht.

>> Ansonsten ist das Web voll davon, such mal nach "Schichtenmodell",
>> "Three tier architecture", "Mehrschichtige Architektur" o.ä.
> ok. Danke.
> Dennoch kannst Du gute Bücher in Zusammenhang mit C# empfehlen?

Ich könnte dir sicher ein paar gute Bücher über Softwarearchitektur und
-Design empfehlen, die ich gelesen habe, aber keines davon ist speziell
für C#, und viele davon waren auch nicht deutsch. Du müsstest vielleicht
ein wenig konkreter sein, wo du derzeit stehst und was du suchst.

Grüße

- Michael -