Training - Beratung - Projektarbeiten

www.David-Tielke.de

C# Beispielprojekt zur CoCo Architektur jetzt auf GitHub

In den letzten drei Ausgaben der dotnetpro durfte ich in der Artikelserie zur "Pragmatischen .NET-Architektur" eine pragmatische Architektur vorstellen, die nicht nur in fast allen Projekten einsetzbar ist, sondern für Entwickler auch besonders einfach zu verstehen und kinderleicht umzusetzen ist. Das im letzten Teil entwickelte Beispielprojekt "KontaktManager" steht jetzt als Projekt auf GitHub zur Verfügung.

Zu dem Thema CoCo wird auf diesem Blog in Kürze eine Webcastreihe erscheinen, die Grundlagen und Praxiseinsatz beleuchten werden.

Links
CoCo KontaktManager C# auf GitHub

Kommentare (3) -

  • W Böck

    03.07.2015 09:54:15 | Antwort

    Hallo David,

    ich war mit ein paar Kollegen auf der DWX 2015 und wir haben dort mit großem Interesse Deine Vorträge zur Composite Components Architektur verfolgt.
    Wir finden den Ansatz sehr interessant und würden das Ganze gerne bei unserem nächsten Projekt einsetzen.

    Leider hatten wir nicht die Möglichkeit, am Freitagsworkshop teilzunehmen.
    Deswegen wollte ich jetzt Deinen KontaktManager auf GitHub (Stand 03.07.2015) als Referenz hernehmen.


    Ein paar Fragen dazu:

    1. Die Klasse Person beinhaltet nur Properties und keine Geschäftslogik.
    Die vorhandene Logik befindet sich im PersonManager. ("wann ist eine Person Adult/Child")
    Sollte ich generell Geschäftslogik in den PersonManager packen und in der Person Klasse nur die Daten ablegen?


    2. IPersonRepository verlangt die Implementierung von IQueryable<Person>

    Kann ich für die Implementierung NHibernate nutzen? Wenn ja, wie?
    (Ich schaffe es irgendwie nur, wenn ich jedesmal die ganze Tabelle als List<Person> in den Speicher lade.)


    3. Im Beispielprojekt gibt es nur Lese-Operationen.

    Wie sollte ich das Speichern einer Person implementieren?



    Grüße und vielen Dank im voraus!

  • David

    21.10.2015 10:12:20 | Antwort

    Zu deinen Fragen:

    F1: Genau, Logik kommt in die Manager (die muss ja austauschbar sein), während die Daten in den DataClasses und damit im CrossCutting oder in den Component Contracts liegen.

    F2: IQueryable wird ja benutzt, um ein Rohquery mit LINQ aus der Datenschicht zu holen, dieses oben in der Logik genauer zu definieren (Filter, Sortieren, etc) und danach im Datenlayer ausführen zu lassen, gegen die entsprechende LINQ Provider der Datenschicht. Ob das nun Entity Framework oder NHibernate ist, spielt gar keine Rolle, du musst nur LINQ nutzen um an ein IQeuryable zu gelangen. Wie das geht, zeigt folgendes Tutorial recht gut: mhinze.com/.../

    F3: Schreiboperationen werden genauso implementiert. Du hast eine Update und Insert im Manager, an die Du die Entitäten weitergibst, die wiederum rufen dann entsprechende Operationen im Datenlayer auf.

    Ich hoffe das hilft Dir!

  • W Böck

    22.10.2015 05:07:51 | Antwort

    Hi David,

    alles klar - vielen Dank besonders für die extra Veranschaulichung per E-Mail!

    Wie gesagt war für mich bei Frage 3 der erleuchtende Punkt, dass ich jeweils pro Entity den Update/Insert Aufruf im Manager machen muss und nicht einen ganzen Objektgraph auf einmal 'updaten' kann.

Kommentar schreiben

Loading