ASP.NET MVC - Entfernen von Abhängigkeit von DAL in GUI

Ich baue eine MVC Web App, die aus 3 Projekten bestehen. Eine für die GUI, eine für die BusinessLogic und eine für den Datenzugriff.ASP.NET MVC - Entfernen von Abhängigkeit von DAL in GUI

Für meinen Datenzugriff habe ich eine generierte Datei von EF und daher habe ich eine generierte Klasse namens "Customer". Um Validierungsattribute für diese Klasse zu erstellen, muss MetaDataType erstellt werden (was im selben Namespace erledigt werden muss und daher in der DAL-Schicht erfolgen muss) - indem ich auf die Datenzugriffsebene von meiner GUI aus zugreife was die ganze Idee, das Projekt zu teilen, verdirbt, weil meine GUI jetzt sowohl meine DAL- als auch BL-Ebene betrifft. Kann ich meine GUI- und DAL-Layer trotzdem getrennt halten, aber trotzdem Validierungsattribute wie [Required] und so weiter verwenden?

Vielen Dank im Voraus.

Quelle

2010-12-14 ebb

Wenn Sie .NET 4 (EF 2) verwenden, können Sie POCO-Entitäten in einer separaten Klassenbibliothek generieren, die projektübergreifend verwendet werden kann. Dies erfordert keine Abhängigkeit von der DAL. Siehe meine Antwort:

ASP.Net Layered app - Share Entity Data Model amongst layers

Besonders 3.e POCO-Vorlagen, einschließlich, wie man eigenes Projekt verschieben: http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-poco-templates-for-the-entity-framework.aspx

Quelle

2010-12-14 19:53:17

Wie ich bei meiner Antwort bemerkt habe, mag dies praktisch sein, aber es ist völlig gegen das Konzept der Persistenz Ignoranz - da Sie UI mit dem Domänenmodell mischen würden. Aber niemand ist gezwungen, ein DDD-Programmierer zu sein. – rsenna

@rsenna: Wenn ich mich nicht irre, haben Sie immer noch Ignoranz; Das ist der Sinn von POCO. Solange Sie eine andere Abstraktion haben, wie das Repository-Muster, um die Datenbankaufrufe zu handhaben, können Sie das gesamte Datenbank-Backend ersetzen und Ihre POCO-Entitäten pflegen. Sicher, die POCO-Entitäten werden nicht mehr von EF generiert, aber es gibt keine Abhängigkeit von EF, also spielt es keine Rolle. –

Das Problem, das ich sehe, ist nicht technisch, sondern architektonisch - Sie teilen die ** gleichen ** Entitäten über DAL und UI. Die Präsentation ist also mit denselben Entitäten gekoppelt, die für die Persistenz verwendet werden - und ich glaube nicht, dass dies "Ignoranz" genannt werden könnte ...Aber wieder habe ich das schon einmal gemacht und würde es für einfache Systeme oder stark CRUD-orientiert tun. Alles andere als das würde ich mit Viewmodels für die UI und Domänenentitäten für die Business- und Datenzugriffsebenen gehen. – rsenna

Das ist, was ViewModels sind. Aber das bedeutet, dass Sie eine neue Reihe von DTOs für die View-Controller-Kommunikation haben werden ... Was eine gute Sache ist, IMHO, da Ihre Ansichten nichts über das reale Domain-Modell wissen sollten.

In Bezug auf alle verschiedenen Möglichkeiten, Ihre Ansichten mit dem Modell kommunizieren zu lassen, sehen Sie sich bitte this an.

Quelle

2010-12-14 19:43:18 rsenna

Those „Viewmodel“ - sollten sie meine BL-Schicht übergeben werden und „verpackt“ in die EF generierte Klassen? – ebb

Nein, Viewmodels sollten nur von den Views und den Controllern gesehen werden - sie sind ** nicht ** Teil Ihrer BL oder DAL. Stellen Sie sich diese Daten als Daten vor, die der ** Benutzer ** sieht - was wahrscheinlich sehr unterschiedlich ist, da dieselben Daten in Ihrem Domänenmodell beibehalten werden. – rsenna

Was soll ich tun, wenn ich eines meiner Viewmodels an die BL weitergeben möchte? - Oder verwenden Sie normalerweise keine Klassen als Parameter? – ebb

ASP.NET MVC - Entfernen von Abhängigkeit von DAL in GUI

Antwort

Verwandte Themen