Drei Schichten-Architektur Frage

Question

Ich habe eine ASP.NET-Anwendung mit einer dreischichtigen Architektur:

• Darstellungsschicht: ASP.NET

• Bussiness Schicht:. C # Bibliothek

• Data Access Layer: C # Bibliothek
  ADO.Net Entity Framework-Objekte.

Einige Methoden auf Bussiness Schicht würden ADO.NET Entity-Objekte zurück, sondern, Datenzugriffsschicht auf Präsentationsschicht nicht sichtbar ist, kann ich das nicht.

Meine Frage ist: Auf einer Entwurfsansicht Ist es richtig, Entity Objekte in der Darstellungsschicht zu? Ich glaube, ich muss nur Data Layer Bibliothek mit ASP.NET App verknüpfen.

Danke!

Answer 1

Ich schlage vor, dass Sie die Konzepte sehen in der Ansicht Objekte ... oder Data Transfer Objects (DTO). Sie könnten mit einem Werkzeug wie AutoMapper oder ähnlich betrachten, die eine Ansicht spezifisches Domain-Objekt aus Ihren Einheiten schaffen. Im Allgemeinen können Sie Bildschirme haben, die ein Unternehmen vorhanden müssen ihre Arbeit verrichten. Aber mehr als oft nicht, müssen Sie mehrere verschiedene Entitäten zu übergeben. In diesem Fall sind Sie besser dran, ein DTO zu schaffen, die alle diese Einheiten enthält. Auf diese Weise Sie das Hinzufügen einer Schicht der Trennung zwischen Präsentationsschicht und Ihre Business-Schicht. Oft Ihre Entitäten haben mehr Macht, als Sie Ihre Präsentationsschicht aussetzen möchten. Und umgekehrt. Häufig müssen Sie möglicherweise einige UI-Nachrichten an die Präsentationsschicht auf etwas in Ihrer Business-Schicht gekennzeichnet Validierung basiert erhalten. Anstatt Ihre ui komplexer zu machen, als es sein muss (durch in Ihren vollständigen Entitäten vorbei) können Sie nur in geben, was in Form der DTO die Benutzeroberfläche benötigt. Außerdem gibt es nie eine Notwendigkeit für Ihre Business-Objekte über etwas Bestimmtes an die Präsentationsschicht zu kümmern. Ich schlage vor, dass Sie nicht direkt etwas Databind so weit zurück wie die Datenzugriffsschicht. Technisch sollte Ihre Präsentationsschicht über Ihre Business-Schicht so wenig wie möglich wissen. Im Fall von MVP oder MVC ist dies sehr einfach durch Abziehen des vorderen Endes und des hinteren Endes durch diese zusätzliche Trennung zu erreichen!

Answer 2

Es ist absolut wünschenswert, um Ihre Einheit für die Verwendung und den Verbrauch in der Präsentationsebene zur Verfügung Objekte. Das ist, was die ganze Arbeit ist für.

• Binde Sammlung von Objekten zu einem Raster / Listview / Drop-down
• ein einzelnes Objekt Spritzen (d Kunde) auf eine Form für Schreib- / update / delete

Das macht Ihnen das Leben leichter bei weitem. Andernfalls würden Sie Zeichenfolge nach int nach double nach Zeichenfolge zwischen Präsentation und Business-Schichten übergeben.

Diese können Entity-Objekte sein oder sogar Ihre eigenen POCO-Objekte, die von den Entity-Objekten mit Feuchtigkeit versorgt wurden.

Ich würde sogar so weit gehen zu sagen, dass Ihr entites von der DAL in ihrer eigenen Montage trennt sein sollte.

Answer 3

ich nicht denke, es ist nicht der beste Weg, dies zu tun ist, Datenklassen von Verhalten zu trennen und nur als Referenz Datenklassen in der Darstellung level.The guter Ansatz denke ich WCF zu verwenden, finden Sie in diesem link

Answer 4

Siehe Supervising Controller- und Passive Ansicht

Wenn Sie die Entity passieren, Sie sind im Wesentlichen Supervising Controller. Ansonsten sind Sie Passive Ansicht.

Controller Supervising ist weniger Arbeit, aber weniger prüfbar. Supervising-Controller sagt auch Databinding in Ordnung ist. Passive Ansicht ist überprüfbar, aber viel mehr Arbeit. Keine Datenbindung. Viele Eigenschaften.

Normalerweise bleibe ich mit Controller Supervising. Sie müssen in der Regel nicht, dass die Höhe der Testbarkeit und es ist nicht wert, die zusätzlichen Schwierigkeiten.