Welches bevorzugen Sie für die Suche / Berichterstattung Datatable oder DTO oder Domain-Klasse?

Question

Das Projekt zur Zeit arbeite ich erfordert in vielen searhing / Filterung Seiten. Zum Beispiel habe ich eine aufwendigere Suchseite zu bekommen Probleme von Daten, die Kategorie, Einheit, ...

Ausgabe Domain-Klasse ist komplex und enthält viele Wertobjekte und untergeordnete Objekte.

.Ich frage mich, wie die Menschen beschäftigen sich mit Searching / Filtering / Berichterstattung für UI. Soweit ich weiß, ich habe drei Optionen, aber keiner von ihnen mich glücklicher machen.

1.) Parameter schicken Repository / DAO Datentabelle und Bind Datatable UI Controls.For Beispiel zu ASP.NET Gridview Get

DataTable dataTable =issueReportRepository.FindBy(specs);
.....
grid.DataSource=dataTable;
grid.DataBind();

Bei dieser Option kann ich einfach durch das Domain-Layer und Abfrage-Datenbank für bestimmte Spezifikationen übergeben. Und ich nicht vollständig aufgebaut komplexes Domänenobjekt zu bekommen. Keine Notwendigkeit für Wertobjekte, untergeordnete Objekte, .. Daten Get in UI in Datatable angezeigt direkt aus der Datenbank und zeigt in der Benutzeroberfläche.

Aber wenn eine berechnete Feld in UI wie Rückgabewert der Methode zeigt, muß ich habe dies in der Datenbank zu tun, weil ich habe nicht vollständig Domain-Objekt. Ich muss Logik und Datatable Probleme wie kein intellisense Duplikat etc ...

2.) Parameter senden an Repository / DAO DTO und Bind DTO Get Controls UI.

IList<IssueDTO> issueDTOs =issueReportRepository.FindBy(specs);
....
grid.DataSource=issueDTOs;
grid.DataBind();

Bei dieser Option ist das gleiche wie wie oben, aber ich muß anämisch DTO erstellen Objekte für jede Suchseite. Auch für verschiedene Ausgabe-Suchseiten habe ich verschiedene Teile der Ausgabe zeigen Objects.IssueSearchDTO, CompanyIssueTO, MyIssueDTO ....

3.) Senden Sie Parameter zu Real Repository-Klasse vollständig aufgebaut Domain-Objekte zu erhalten.

IList<Issue> issues =issueRepository.FindBy(specs);
//Bind to grid...

Ich mag Domain Driven Design und Muster. Es gibt keine DTO oder Duplizierung Logik in diesem option.but in dieser Option, die ich viel von Kind und Wert-Objekt erstellen, die in der UI.Also nicht gezeigt werden erfordert es viel ist ob vollständige Domain-Objekt und Performance Kosten für Nadeln Kind bekommen beitreten Objekte und Wertobjekte.

ich jedes ORM-Tool nicht Vielleicht verwende ich Lazy Loading-von Hand für diese Version implementieren kann, aber es scheint ein wenig übertrieben.

Welche bevorzugen Sie? Oder bin ich es falsch? Gibt es irgendwelche Vorschläge oder besseren Weg, dies zu tun?

Answer 1

Ich habe ein paar Vorschläge, aber natürlich auch die Gesamt Antwort ist „es kommt“.

Als erstes sollten Sie ein ORM-Tool verwenden oder Sie sollten einen sehr guten Grund haben dies nicht zu tun.

Zweitens Umsetzung Lazy Loading-von Hand ist relativ einfach so in dem Fall, dass Sie nicht ein ORM-Tool nicht benutzen wollen, können Sie einfach Eigenschaften auf Objekte erstellen, die wie etwas sagen:

private Foo _foo;
public Foo Foo
{  
  get {  
         if(_foo == null)
         {
            _foo = _repository.Get(id);
         }
         return _foo;
       }
}

Drittens ist die Leistung etwas, das zunächst in Betracht gezogen werden sollte, aber Sie sollten nicht von einem eleganten Design verjagen. Ich würde behaupten, dass Sie (3) zunächst und nur davon abweichen, wenn die Leistung nicht ausreicht, verwenden sollen. Daraus ergibt sich die geringste Menge an Code zu schreiben und die geringste Vervielfältigung in Ihrem Design haben.

Wenn die Leistung leidet man es leicht in der UI-Ebene adressieren kann Caching und / oder in Ihrer Domain Schicht Lazy Loading-verwenden. Wenn diese beiden nicht akzeptable Leistung liefern, dann können Sie wieder auf einen DTO-Ansatz fallen, wo Sie nur eine leichte Sammlung von Wertobjekten benötigt passieren zurück.

Answer 2

Dies ist eine groß Frage und ich wollte meine Antwort auch liefern. Ich denke, die technisch beste Antwort mit Option # 3 zu gehen. Es bietet die Möglichkeit, am besten beschreiben und die Daten zusammen mit Skalierbarkeit für zukünftige Erweiterungen zu Reporting / Such Anfragen zu organisieren.

Jedoch , während dies die insgesamt beste Option sein könnte, gibt es ein enorm Kosten IMO gegen die anderen (2) Optionen, die die zusätzliche Entwicklungszeit für alle Klassen und Beziehungen erforderlich sind zur Unterstützung des Bedürfnisse (wieder unter der Prämisse, dass es kein ORM-Tool verwendet wird) berichten.

Ich kämpfe mit diesem in vielen meine Anwendungen als auch und die Realität ist, dass 2 # der beste Kompromiss zwischen Zeit und Design. Nun, wenn Sie über Ihre busniess Objekte gefragt wurden und alle ihre Bedürfnisse gibt es nicht Frage, dass ein vollständig angelegt und richtig ausgelegt Modell wichtig ist, und es gibt keinen Ersatz. Allerdings, wenn es um die Berichterstattung und die Suche dies zu mir kommt, ist ein anderes Tier. # 2 liefert stark typisierte Daten in den anämischen Klassen und ist nicht so primitiv wie fest einprogrammierte Werte in Dataset wie # 1, und reduziert noch stark die Menge an Zeit, um das Design im Vergleich zu # 3 abgeschlossen erforderlich.

Im Idealfall würde ich gerne mein Objektmodell erweitern alle Reporting-Anforderungen umfassen, aber manchmal ist der Aufwand, dies zu tun, ist so umfangreich, dass eine separate Gruppe von Klassen zu schaffen nur für Bedürfnisse Berichterstattung ist ein einfache, aber immer noch gangbarer Weg. Ich fragte tatsächlich fast diese identische Frage vor ein paar Jahren und wurde auch gesagt, dass eine andere Gruppe von Klassen zu schaffen (im Wesentlichen DTOs) für Bedürfnisse Berichterstattung war keine schlechte Option.

So ist es einpacken, # 3 ist technisch die beste Option, aber # 2 ist wahrscheinlich die realistischste und praktikable Option, wenn die Zeit und Qualität zusammen für komplexe Berichterstattung und die Suche Bedürfnisse berücksichtigen.