Architektonische Frage für die Entwicklung von Tier .Net

Question

Hallo zusammen, ich bin ziemlich neu im gestuften Entwicklungsprozess. Ich entwickle derzeit eine App und habe einige grundlegende Fragen zu bewährten Praktiken / architektonischen Fragen mit der heutigen Technologie. Ich werde WCF als Service-Schicht verwenden. Beachten Sie, dass ich versuche, Dinge so weit wie möglich zu entkoppeln. Ich möchte nicht, dass die oberen Ebenen über Dinge in den unteren Ebenen Bescheid wissen, was einer der Gründe ist, warum ich LINQ TO SQL oder das Entity Framework nicht mag.

1) Was ist der beste Weg, um Daten zwischen den Ebenen zu übergeben? Ich weiß, dass entweder ein Dataset oder eine DataTable einfach wäre, aber ich denke nicht, dass das Weitergeben dieser aufgeblähten Datenstruktur zwischen den Ebenen die beste Lösung wäre. Auch das Debuggen wäre schwieriger, wenn die DataTables / Datasets groß wären. Wäre vielleicht ein Array von POCO-Objekten die beste Lösung oder gibt es einen besseren Weg?

2) Die nächste Frage ist etwas kniffliger. Viele Anwendungen werden eine Vielzahl unterschiedlicher Ansichten der Daten haben. Sie könnten mehrere Berichte, verschiedene Datagrids und vielleicht ein oder zwei Diagramme haben. Wie gehen Sie beim Entwerfen Ihrer Datenschicht damit um? Entwerfen Sie einfach eine Art "Get"-Funktion für jede Tabelle und versuchen Sie dann, sie in nützliche Ansichten für z.B. ein Raster oder einen Bericht in Ihrer Geschäftsschicht zu kombinieren, oder haben Sie eine spezialisierte Funktion für jede Ansicht, die Sie in der Geschäftsschicht benötigen.

Ehrlich gesagt mag ich keine der Lösungen. Wenn Sie sich für spezialisierte Logik pro Ansicht entscheiden, müssen Sie ein POCO-Objekt erstellen (unter der Annahme, dass Sie ein Array von POCO-Objekten zurückgeben werden) pro Ansicht. Wenn Sie später feststellen, dass Sie einer der Ansichten mehr Spalten hinzufügen müssen, würden Sie den bestehenden Code brechen (weil Sie die Schnittstelle am POCO ändern). Wenn Sie eine Ansicht jeder Tabelle zurückgeben und versuchen, sie in der Geschäftsschicht zu kombinieren, könnte das wirklich unübersichtlich werden. TSQL hat Joins aus einem Grund :). Außerdem könnten Sie je nach Design möglicherweise viel mehr Daten zurückgeben, als Sie benötigen, was ineffizient wäre.

Ich habe noch einige Fragen, aber ich werde das für später aufbewahren. Ich möchte nicht, dass dieser Beitrag zu groß wird :)

Ncage

Answer 1

Gute Fragen. Wichtige Sachen, das hier. Im Allgemeinen ist einer der besten Wege, um sich an gestaffelte Lösungen heranzutasten, Interfaces zu betrachten. Interfaces sind eine Möglichkeit, "engpasspunkte" bereitzustellen, die mehrere nützliche Zwecke erfüllen können.

Innerhalb gestaffelter Lösungen dienen Interfaces dazu, das Verhalten der Ebenen zu erzwingen; effektiv, indem man den Satz von Verhaltensweisen definiert, den man erwartet, entkoppelt man die Implementierung der Ebenen. Das heißt, solange meine Ebene das Interface ordnungsgemäß implementiert, brauche ich mich um die Implementierung überhaupt nicht zu kümmern.

Ich bringe das zur Sprache (und das IST relevant), weil bei der Definition Ihrer Interfaces auch die Daten definiert werden müssen, die zwischen den Ebenen übergeben werden. Wenn Sie also definieren, was zwischen den Ebenen geschehen soll, definieren Sie auch, welche Daten übergeben werden; und gleichzeitig definieren Sie einen strengen Satz von übergebenen Daten.

Ein relevanter Punkt hier zur Trennung ist, dass keine Informationen zur Implementierung einer Ebene zwischen den Ebenen übergeben werden sollten. Mit anderen Worten, durch die Definition Ihres Interfaces und die strenge Einhaltung der Implementierung sollten Sie es möglich machen können, dass die Implementierung der Ebene neu implementiert werden kann, wissend nur über das Interface, und die andere Implementierung ohne Probleme ersetzen kann.

Wenn Sie dies wissen, wird es einfach; die Verwendung von einfachen alten Objekten wird im Allgemeinen Ihre Interfaces sauber und ordentlich halten; und es hält Ihre Datenstrukturen davon ab, aufgebläht zu werden. Es dient auch dem Zweck, der Versuchung zu widerstehen, einige Informationen zur Implementierung einer Ebene in einer anderen Ebene zu verwenden.

Natürlich ist es sinnvoll, einen langfristigen Blick auf das zu lösende Problem zu werfen; welche Operationen wird der Benutzer durchführen wollen? Diese Operationen lösen sich in der Regel in "Verben" auf, die gut zu Interface-Definitionen passen, die den Vertrag definieren, den die Geschäftsobjekte implementieren werden. Die Datensätze, auf denen Ihre Geschäftsobjekte arbeiten werden, definieren die Ansichten, die Sie auf Ihrer Datenbank haben müssen. Auf diese Weise können Sie Ihre Trennung sauber aufrechterhalten.

Answer 2

Dies sind sehr gute Fragen. Es gibt viele mögliche Antworten und viele mögliche Architekturen. Ich empfehle Ihnen, einen Leitfaden zu dem Thema zu lesen. Patterns & Practices hat einen sehr guten. Es ist kostenlos, umfassend und behandelt ausführlich die Fragen, die Sie stellen. Kein Architekturleitfaden ist perfekt, aber als Ausgangspunkt denke ich, dass es nicht verkehrt ist, sich mit den Grundlagen vertraut zu machen.

Answer 3

Ich glaube, dass du ein wenig von der Idee abweichst, dass der Datentier nichts über das Geschäfts- oder UI-Tier wissen sollte. In einem ORM-Tool (zum Beispiel LINQ to SQL) werden die Eigenschaften deiner Entitäten durch die Daten bestimmt. Es gibt wirklich keinen Grund, das nicht zu tun. Das Verwenden von stark typisierten Entitäten ist nicht dasselbe wie das Einbinden von Geschäfts- oder UI-Logik im Datentier und ist im Allgemeinen eine gute Sache. Wie du dorthin gelangst, liegt bei dir.

Ich plädiere IMMER dafür, eine stark typisierte Komponente zu verwenden, um Daten weiterzuleiten, anstatt ein allgemeines Repository wie ein DataSet/Table/Row/View usw. zu verwenden.

Vielleicht könntest du ein wenig erläutern, was dich von diesem Ansatz abgebracht hat?