Hi,

ich versuche gerade, ein sinnvolles Projektmanagement anzueignen, also das Projekt so aufzubauen, dass die ganzen Qualitätsmerkmale, Wartbarkeit, etc. auch gegeben sind.

Die Überlegung dabei war, dass ich das Programm in drei Schichten aufteile.

Testweise das Projekt EmployeeManager, welches eigentlich nur eine simple Mitarbeiterverwaltung darstellt.

Das Projekt besitzt drei Schichten, einmal die Logik-Schicht, wo eigentlich alles passiert, die UI-Schicht, welche dann die Oberfläche darstellt und als Drittes die Verbindung zwischen Beidem.
Die Logik-SChicht ist ganz einfach, eine Employee-Klasse, welche hauptsächlich Daten bereit stellt, eine EmployeeManager-Klasse, welche dafür gedacht ist, die Mitarbeiter in einer Liste bereit zu stellen und diese auch zu verwalten und noch weitere Klassen, wie die Adress-Klasse, die einfach nur die Adress-Daten des Mitarbeiters kapseln soll.

Die Verbindungsschicht ist komplett nach einem Interface IView aufgebaut, das nur die Methoden GetData und SetData bereit stellt. Dann gibt es zu jeder Klasse eine weitere View-Klasse (EmployeeView, EmployeeManagerView, etc.), welche dann die Daten aus der Logik-Schicht aufbereiten soll.

In der UI-Schicht werden dann die von der Verbindungs-Schicht aufbereiteten Daten dargestellt oder vom Nutzer bearbeitet.


Das Problem an der Sache ist jetzt, dass ich nicht weiß, wie die Daten aufbereitet werden sollen und wie allgemein alles sinnvoll zusammen arbeiten soll.
Zuerst sollte die Oberfläche eine Konsole sein, soll aber auch später durch eine andere Oberfläche (Forms/WPF) ersetzt werden können und da stellt sich das erste Problem: Wie sehen aufbereitete Daten aus, mit denen diese Technicken klar kommen?
Da hatte ich mir überlegt, für jede mögliche angezeigte Information einen Key in einem Dictionary anlegen und als Value dann den Datenwert. In der Konsole könnte man das dann einfach Zeile für Zeile darstellen und bei WindowsForms könnte man dann einfach die Werte in die passenden Textboxen rein schreiben.
Mit WPF kenne ich mich noch nicht so gut aus, dass ich das entsprechend voraus planen könnte.

Nun stellt sich mir aber die nächste Frage:
Welche Daten werden aufbereitet? Wenn in der Klasse Employee die Daten alle direkt und simpel als Wert gespeichert wären, könnte ich die auch so bereit stellen. Da ich aber noch eine Adresse als extra Objeckt habe, Telefonnummern, eMail-Adressen, etc., für die es auch jeweils eine View-Klasse gibt, weiß ich nicht, wie ich damit umgehen soll. Soll ich dann direkt in EmployeeView die Adresse ebenfalls anzeigebereit ausgeben, oder eher das Objekt, das dann wieder über AdressView aufbereitet werden soll?



Viele Fragen, den Gedanken hinter dem System hab ich kapiert, denn dann muss bei Änderungen in z.B. Employee nur noch EmployeeView angepasst werden und der Rest funktioniert trotzdem. Wenn die Oberfläche gewechselt werden soll, dann interessiert das nicht die Logik, sondern maximal die Verbindungs-Schicht und die wenn möglich auch nicht. Nur wirklich umgesetzt kriege ich das nicht.

Gibt es dafür vielleicht auch ein entsprechendes Pattern, wo ich dann genauer nach suchen und mich informieren kann?


Grüße


Edit: Vielleicht wäre es sinnvoller, wenn das ein freundlicher Moderator in ein allgemeineres Forum verschieben kann, schließlich betrifft das nicht nur C#, sondern ist ein Thema, das zu jede objektorientierte Programmierung passt.

Zitat:

Das Problem an der Sache ist jetzt, dass ich nicht weiß, wie die Daten aufbereitet werden sollen und wie allgemein alles sinnvoll zusammen arbeiten soll.

In erster Näherung würde ich sagen gar nicht. Daten in einer von der UI nutzbare Form aufzubereiten ist eine Aufgabe der konkreten UI.

Vielleicht hilft dir die Vorstellung mehr als ein Model zu haben. Einmal das Servicemodel auf das deine Logik angewendet wird und das zum Bespiel oft auch Richtung Persistenz hin optimiert ist und jeweils ein UI Model für die konkrete Darstellung. Da du konkret nach der Verbindungsschicht fragst ist dann die zentrale Aufgabe dieser Verbindungsschicht UI-Model(e) auf das Servicemodel zu mappen.

Ich weiß nicht, was du meinst.


Aber du sagst, dass das Aufbereiten der Daten Aufgabe der UI ist. Aber wie gebe ich die Daten dann an die UI weiter, dass ich dort bei Änderungen der Logik oder Erweiterung der Klassen (neue Eigenschaften, etc.) nicht zu viel, oder besser gesagt nichts, ändern muss?
Daher dachte ich, dass ich die Daten via Dictionary weiter gebe, das dann in der UI in einer Schleife durchgelafen werden kann.

Zitat:

Aber wie gebe ich die Daten dann an die UI weiter, dass ich dort bei Änderungen der Logik oder Erweiterung der Klassen (neue Eigenschaften, etc.) nicht zu viel, oder besser gesagt nichts, ändern muss?

Du gibst die entsprechenden Modelklassen an die UI. Diese wird diese Klassen auf ihr eigenes UI Model mappen(oder kapseln) und verwenden. (UI denke ich mir nicht nur als die Form oder ähnliches sondern selbst als ein System aus Klassen. Üblicherweise irgendwas aus der MV(XXX) irgendwas Ecke)
Wenn dein ServiceModel dem Ideal von POCOs nahe kommt man spricht dann gern auch von DataTransferObjects (DTO) sollte die konkrete Logik dann für die UI unerheblich sein und sie kann sich auf ihre eigentliche Aufgabe konzentrieren und das Zeug darstellen.

Zitat:

Daher dachte ich, dass ich die Daten via Dictionary weiter gebe, das dann in der UI in einer Schleife durchgelafen werden kann.

Dictionary hört sich für mich problematisch an das du dann schon irgendwie einen Key aus den Daten extrahiert hast um etwas spezielles damit zu machen. Bei Model Klassen gehört das identifizierende Merkmal eher zu den Daten selbst und nicht als extra Key in ein Dictionary. Der Transport von Daten sollte also eher rudimentärer mit irgendwelchen Enumerables staffinden wenn nötig. Wenn in der UI ein Dictionary notwendig wird dann wäre das eine Aufgabe des Modelmappings den Key aus den Modeldaten zu extrahieren und dann ein entsprechendes Dictionary im UI Model zu erzeugen.

Im Dictionary wäre der Key der Name des Wertes, also z.B. das Geburtsdatum und so kann es dann auch angezeigt werden.


Gibt es irgendeinen Namen dafür, damit ich mir auch sowas wie ein Beispiel raus suchen kann, weil irgendwie steige ich nicht so ganz dahinter.

Du willst dein ganzes Model als einen Sack von Key-Value Pairs darstellen? Aua.

Was anderes viel mir halt nicht ein und bei der Konsole hätte das ganz gut funktioniert, weil ich dann einfach links EIgenschaftenname und rechts den Wert, getrennt von einem Doppelpunkt, hätte schreiben können.

Das das auf Dauer nicht viel her macht, ist mir klar, aber was besseres fällt mir einfach nicht ein.
Vielleicht XML, aber wie soll das dann in XML dargestellt werden? Wäre es nicht sinnvoller, dann gleich das ganze Objekt zu übergeben?

XML wäre ja rein logisch nur eine Textdarstellung eines Objekts. Ob der Transport zwischen den Schichten nun als Object oder XML stattfindet ist dann mehr eine Frage welche Grenze zwischen den Schichten überwunden werden muß.

Ein solches Objekt/XML wäre dann aber für Transport ausgelegt und nicht für Darstellung. Sobald du versuchst das zu kombinieren wirst du dir bezüglich Wiederverendbarkeit ein Bein stellen. Versuche nicht dir das zu transportierende Objekt so hinzubasteln das ein bestimmter View einfach wird. Es wird nur dafür sorgen das es für andere Views schwieriger wird.

Und wie mache ich das dann besser?

Soll ich dann in den View-Klassen tatsächlich einfach nur die Objekte durch reichen?


Sorry, aber irgendwie steh ich total auf dem Schlauch und weiß nicht wirklich weiter.
Entweder ich programmiere weiterhin so wie bisher und falle bei größeren Projekten dann früher oder später auf die Nase, oder ich versuche jetzt, mir eine anständige Vorgehensweise anzueignen um dann auf lange Sicht besser zu werden.

Wenn du da bestimmte Programmierstile trainieren willst würde ich empfehlen da sowas wie ein MVC Muster zu probieren. Ist letztlich nur eine andere Sichtweise auf ein Schichtenmodell. ISt aber klarer definiert und du findest einfacher Material. Dein Gedanke mit größeren Projekten ist glaube ich gerade nicht hilfreich da die entsprechenden Muster und Vorgehensmodelle erst wirklich relevant werden bei Teams größer 1. Und ich glaube nicht daran das man die Methoden im kleinen vernünftig lernen kann. Das füllt sich dort dann immer nur an wie ein Klotz am Bein. Was es dann auch irgendwie ist Schreckt nur ab. Ein kleines Projekt geht man anders an als ein großes.

Was man lernen kann und nachhaltig hilft sind aber die typischen Designmuster die sich festgesetzt haben. Also MVC oder ein Derivat davon und dazu irgendwann das Service Locator Pattern. Mit den beiden Patterns kann man eine typische Businessapplikation eigentlich fast 100% abdecken ohne irgendwo ein ~Designloch~ zu haben. Was dann noch dazukommt bei größeren Projekten sind eigentlich nur noch Dinge die Teamprobleme lösen sollen oder spezielle untypische Dinge lösen sollen.

Also über Tipps für ein Team bin ich auch dankbar, weil die ganze Problematik hat sich während der Ausbildung zum Fachinformatiker gestellt, allerdings kann ich die Kollegen hier nicht ständig nerven, da sie im Moment sehr viel zu tun haben. Daher möchte ich mich selber entsprechend informieren. Das ist auch nicht weiter schwer, hab ja im alleingang C# gelernt und ich kann dann mein Wissen den anderen Azubis bereit stellen.


Also erst einmal vielen Dank für die vielen Stichworte und Namen, jetzt habe ich zumindest schon mal etwas, wonach ich direkt suchen kann. Ich hab mir auch das Buch "Patterns kompakt" gekauft, vielleicht finde ich da ja was gutes zu dem Thema.

Ich werde das alles nacheinander mal nach lesen und mich dann wieder melden. ^^