Ich bin sehr beschäftigt mit der Architektur einer neuen MVC-Anwendung, aber ich bin sehr verwirrt darüber, wie man verschiedene Arten von Objekten verwaltet. Die Verwirrung betrifft die Beziehung zwischen Entitäten, Geschäftsobjekten und Viewmodels. Ich werde meine Verwirrung mit einem Beispiel beschreiben:
Ich habe meine Webanwendung mit verschiedenen Projekten eingerichtet: MVC Frontend, BLL, DAL, Common dinge etc.
Sagen wir, ich habe eine Aussicht mit einer Liste von Fahrrädern. Ich möchte die Fahrraddetails wie Farbe, Größe, Hersteller anzeigen. Aber in meiner Datenbank sind Fahrrad und Hersteller zwei verschiedene Tabellen, also sind dies in meinem Entity Framework-Kontext auch zwei verschiedene Klassen.
Also ich habe diese zwei Einheiten Bike und Hersteller. Aber in meinen geschäftlichen Bedürfnissen denke ich, dass sie ein einzelnes Objekt sein müssen, das ich manipulieren oder in der Geschäftslogik verwenden kann. Dann gibt es meine Ansicht, die ein (Ansichts-) Modell benötigt. Das sollte auch ein kombiniertes ViewModel mit Eigenschaften aus verschiedenen Tabellen sein.
Wie gehe ich damit um? Muss ich das Bike- und Manufacturer-Objekt von meinem DAL beziehen und ein Business-Objekt daraus in meinem BLL erstellen, und nachdem ich eine Geschäftslogik erstellt habe, sollte ich daraus ein ViewModel in meinem Controller erstellen? Oder muss meine DAL ein kombiniertes Geschäftsobjekt zurückgeben? Oder kann ich das Entitätsobjekt als Business-Klassen verwenden? Oder kann ich mein Business-Objekt auch als ViewModel verwenden?
Ich hoffe, dass mein Problem klar ist und dass jeder mir einen guten Rat geben kann, welches Objekt benötigt wird und wie, wo und wann die verschiedenen Arten von Objekten erstellt werden und in welcher Ebene diese Klassen gehen sollen ...
Die Antwort auf Ihre Frage ist einfach. Zwischen den verschiedenen Ebenen von Modellen besteht eine NO Beziehung. Sie sind vollständig isoliert und beziehen sich nicht aufeinander. Ganz und gar nicht. Daher gibt es nichts zu verwechseln.
Sie haben Code in verschiedenen Teilen Ihres Layers, der zwischen zwei Layern UI- & gt; Business und Business- & gt; Daten abbildet, aber das sollte das Ausmaß jeglicher Interaktion zwischen ihnen sein.
Sie können benutzerdefinierte Geschäftsentitäten verwenden, auf die in Ihren Ansichten verwiesen wird.
In Ihrer Business-Implementierung können Sie einen Mapper verwenden, der Ihre Entity Framework-Entitäten Ihren benutzerdefinierten Geschäftseinheiten zuordnet, die Sie verwenden können Automapper , um dies zu erreichen.
Ich hoffe, das wird helfen.
Sie sollten einige allgemeine Funktionen haben, bei denen Sie alle Zuordnungen für Ihre Business- und EF-Entitäten haben.
und in Ihrer Implementierung werden Sie nur Ihren Mapper bitten, tatsächliche Entitäten bereitzustellen.
Es sollte eine gemeinsame Klasse geben, die Zuordnungen für Sie erstellt.
So ähnlich
public static void CreateTestMapping()
{
Mapper.CreateMap<DataAccess.Entities.Test, Business.Entities>()
.ForMember(s => s.Col1, d => d.MapFrom(t => t.Colabc))
.ForMember(s => s.Col2, d => d.MapFrom(t => t.ReferenceTable.RefTableCol1));
}
In Ihrer Business-Implementierung verwenden Sie diese Zuordnung, um Business.Entities in EF.Entities und umgekehrt umzuwandeln
Mapper.Map<Business.Entities.Test, EF.Entities.Test>(source, destination);
Was ich tun würde, ist:
Ihre DAL gibt List<Bike> und List<Manufacturer> zurück.
Dann sollte Ihre Business-Schicht diese manipulieren und zu asp.net MVC ein entsprechendes Objekt zurückgeben.
Zum Beispiel ein List<Manufacturer> , das für jedes Element ein List<Bike> enthält.
Erstellen Sie die entsprechenden ViewModels und fügen Sie Controller-Logik hinzu, um sie zu manipulieren. ABER TUN Sie KEINE geschäftlichen Manipulationen, sondern nur UI-Manipulationen, die Ihren Ansichten entsprechen.
Ich würde auch empfehlen, Ihre Benutzeroberfläche nicht mit Ihrer DAL zu verbinden.
Behalten Sie für Ihr UI-Projekt einen Verweis auf die allgemeinen Bibliotheken + Business-Layer-Projekt.
Lassen Sie das Unternehmen mit der DAL kommunizieren.
IMHO, ein Teil der Verwirrung kommt von der Tatsache, dass Sie "nicht" alle Verbindungen zwischen Ihren Projekten brechen können, auch wenn Sie für "Design" und Trennung von Anliegen Gründen möchten.
Nun, in der Tat können Sie (und sollten sollten) brechen, aber die Kosten sind, zumindest: verlorene Intelistense und / oder Marshalling-Codierung.
Am Ende sind Ihre Projekte zumindest durch eine Konvention verbunden. Ein Projekt erwartet ein Verhalten von dem anderen. Wenn Sie Wetterdaten veröffentlichen, erwarten Sie, dass Ihre DAL Wetterdaten und keine finanziellen Daten liefert, auch wenn es ratsam ist, den Fall zu bearbeiten.
Mindestens ein Projekt muss eine Schnittstelle / DTO verfügbar machen, und die andere muss diese Schnittstelle implementieren.
Normalerweise und demütig versuche ich, die Geschäftslogik unabhängig zu machen: Geschäft kann ohne Bezug zu irgendeinem anderen Projekt gebaut werden (BITTE: Ich spreche von Projekt, nicht von Schicht). Also Meine abstrakten Klassen oder Schnittstellen sind im Geschäfts- oder Domänenprojekt. Warum: Die wahrscheinlichsten Änderungen sind die Änderung der GUI-Technologie oder die Änderung der Persistenz-Technologie. Wenn Sie also mit mir interagieren wollen, sind hier die Verträge (falscher Freund).
Damit das Projekt auf der Website (oder einem beliebigen GUI) auf das Geschäftsprojekt und das DAL-Projekt verweist, bezieht sich das DAL-Projekt auf das Geschäftsprojekt.
ABER imho, böses beginnt, wenn Sie aufhören, den Umfang Ihres Kontexts zu beherrschen (DbContext, ObjectContext, ...). Andere Sprichwörter versuchen zu vermeiden, ein angehängtes Objekt an Razor zu liefern.
Tags und Links asp.net-mvc c# entity-framework architecture