2011-01-06 6 views
2

Ich arbeite derzeit an einer ASP.NET MVC Reporting-Anwendung mit C#. Dies ist ein Redesign von einer PHP-Anwendung, die gerade erst zusammengeworfen wurde und jetzt beginnt, mehr Traktion zu gewinnen. Wir sind gerade dabei, das Backend zu überarbeiten, um einen OO-Ansatz zu haben. Eine der Entscheidungen, mit denen ich mich gerade befasse, ist die Struktur der Domänenobjekte. Da 95% der Site schreibgeschützt ist, bin ich nicht sicher, ob die typischen Ansätze praktikabel sind.Object model design choice

Sollte ich Domänenobjekte für die primären Teile der Anwendung (Ticket, Zuweisung, Beauftragter) erstellen und dann statische Methoden aus diesen Bereichen erstellen, um die Berichtsdaten zu ziehen? Oder sollte ich diesen Teil überspringen und die Diagrammdatenklassen erstellen und eine "Get" -Methode von diesen Klassen haben? Es ist keine wirklich große Anwendung und derzeit bin ich der Einzige, der daran arbeitet. Aber ich bin verwirrt darüber, welchen Ansatz ich wählen soll. Meiner Meinung nach ist die erste die bessere Wahl, kann aber zu viel sein, wenn man bedenkt, dass die meisten Verwendungen für die aggregierte Berichterstattung verwendet werden.

Hat jemand einen guten Einblick, warum ich so oder so gehen sollte?

+0

war das PHP OO? Wie viel Entwicklung wird es in der Zukunft sehen? Siehe auch http://stackoverflow.com/questions/246808/when-is-object-oriented-not-the-correct-solution –

+1

Nein, es war in keinem Sinn des Wortes 00. Es war eine Gräueltat. Nur ein paar String-Manipulationen. – spinon

Antwort

1

Der Ansatz, den ich wählen würde, ist zunächst, ein konzeptionelles Modell der Problemdomäne zu zeichnen. Meine bevorzugte Methode ist Object Role Modelling, aber es gibt andere, z.B. Entitätsbeziehungsmodellierung.

Ich würde dann mein Objektmodell von diesem konzeptionellen Modell ableiten. Verhaltensweisen, die durch die Problemdomäne definiert sind, sollten dann zu den Objekten in diesem Modell hinzugefügt werden, z. Hinzufügen eines Buches zu einem Buchladen, Geld abheben von einem Konto.

Andere Verhaltensweisen, z.B. das Fortbestehen der Daten in einer Datenbank, die letztendlich für den Benutzer nicht isoliert betrachtet werden soll, sollte zu geeigneten Objekten hinzugefügt werden, die für diese Zwecke erzeugt wurden, z. ein unit of work Objekt, das eine Datenzugriffsschicht (DAL) bilden würde.

Das Modell in Ihrem MVC-Projekt würde in diesem Fall dann aus den Domänenobjekten bestehen, die durch die DAL erweitert werden, und sollte sich natürlich für die Erstellung Ihrer erforderlichen Ansichten und Controller eignen.

Verwandte Themen