Wo sollen meine Models wohnen? Web Tier oder Daten Tier? (MVC + NHibernate)

Ich richte eine n-Tier-Anwendung mit MVC, Ninject und NHibernate (meine erste mit diesen Technologien). Der Übersichtlichkeit halber sind die Schichten eine "Daten" -Stufe, eine "Dienste" -Stufe und eine "Web" -Stufe (alle sind separate Projekte).Wo sollen meine Models wohnen? Web Tier oder Daten Tier? (MVC + NHibernate)

Mit MVC haben Sie Ihre Modelle im Ordner "Models". Es scheint notwendig, meine Modelle hier zu platzieren, um stark typisierte Ansichten zu erstellen und generell mit der Philosophie von MVC zu bleiben.

Allerdings benötige ich mit NHibernate auch meine Modelle in der Ebene "Data", damit das Mapping stattfinden kann und dass NHibernate tatsächliche Objekte instanziieren kann, um zur Services-Schicht zurückzukehren.

Duplizieren der Klassen über Projekte ist nicht sehr trocken und abstrahieren sie in ihre eigene Bibliothek scheint nicht gut mit MVC (weder in der Praxis noch in der Philosophie) zu spielen.

Irgendwelche Gedanken? Wie strukturierst du deine O/RM-Objekte gegen MVC-Modelle?

Quelle

2009-02-13 Jeffrey Harrington

Ich bin gespannt, wie die Passage von 2 Jahren hat diese Frage bestätigt (verfestigt, verstärkt, ua). Ändert MVC3 die Gleichung? Ich bereite mich darauf vor, ein Hybrid zwischen einem älteren nH Daten Tier-to-EF zu erstellen, um Scaffolding zu unterstützen. Was ist die Gruppierung von VS-Projekten beim Mischen von NH und EF heute? - thx – justSteve

Wie wäre es jetzt !? Fast 2 Jahre seit die obige Frage gestellt wurde? –

Ich halte Entity Framework-Modelle/-Klassen in der Datenebene und verwende den Modellordner des MVC-Projekts für Präsentationsmodelle und Modellbinder.

Quelle

2009-02-13 17:56:00

Okay. Es scheint also so zu sein, dass Presentation Models in der Web-Schicht und meine Domain-Modelle in der Data-Schicht beibehalten werden. Also, was sollte meine Services-Ebene auf die Web-Tier zurückgeben? Sollte es über die Präsentationsmodelle wissen? Oder sollte es Domänenmodelle zurückgeben? –

Nein, ich denke nicht, dass die Dienste über Präsentationsmodelle wissen sollten. In der Tat kann ein Service wahrscheinlich nicht jedes mögliche Präsentationsmodell kennen. Der Dienst sollte Übertragungsobjekte zurückgeben, bei denen es sich um Entitätstypen handeln kann. Die Webebene kann dies zu einem Präsentationsmodell machen. –

Das macht Sinn. Dennoch scheint diese Zuordnung von Domänenmodellen zu Präsentationsmodellen nicht sehr DRY zu sein, besonders wenn die beiden Modelle ähnlich sind. –

Ich halte alle meine Modelle in der Datenebene wegen NHibernate. Werfen Sie einen Blick auf S#arp Architecture für eine gute Möglichkeit, Ihre Präsentation sauber zu halten. Modelle müssen nicht physisch in Ihrem Webprojekt lokalisiert sein, damit Ihre Ansichten stark typisiert werden.

Quelle

2009-02-13 18:14:03

Das Datenmodell ist eine eigene Sache. Das Modell in MVC ist etwas anderes. Es ist das Modell dessen, was Sie anzeigen werden. Dies kann Ihr Datenmodell sein oder auch nicht. Ihr Datenmodell kann Layer überschreiten oder nicht.
Nehmen Sie zum Beispiel das Standard-Anmeldeformular. Das Datenmodell kann den Benutzernamen, das Passwort und eine Reihe von Login-History-Klassen, ein Flag, das anzeigt, dass es aktiv ist, und viele andere Dinge enthalten. Das Modell in MVC kümmert sich möglicherweise nur um den Benutzernamen und das Passwort, und der Benutzer gibt das Passwort zweimal ein. Benötigt Ihr Datenmodell wirklich zwei Passwortfelder? Nein, aber das Modell in der MVC tut es. Daher zwei verschiedene Lebewesen.

Quelle

2009-02-13 18:27:51

Okay. Es scheint also so zu sein, dass Presentation Models in der Web-Schicht und meine Domain-Modelle in der Data-Schicht beibehalten werden. Also, was sollte meine Dienste-Ebene auf die Web-Ebene zurückkehren? Sollte es über die Präsentationsmodelle wissen? Oder sollte es Domänenmodelle zurückgeben? –

Die Serviceschicht sollte das Datenmodell zurückgeben. Oder fragen Sie sich: Was passiert, wenn ich auf meine Dienste über eine andere Schnittstelle zugreifen kann? Je weniger Ihr Service-Level über das Frontend weiß, desto besser werden Sie auf lange Sicht sein. –

Mit MVC haben Sie Ihre Modelle, die im Ordner "Modelle" sind. Es scheint notwendig, meine Modelle hier setzen stark typisierte Ansichten und in der Regel mit der Philosophie von MVC.

Kein Modell kann etwas sein, das Sie wollen. Ich würde immer noch ein Präsentationsmodell verwenden, wenn es notwendig wäre, aber ich habe nichts dagegen, Ihre Nhibernate-Entitäten in Ihren Ansichten zu verwenden.

Mit NHibernate brauchen Sie nicht wirklich eine Datenebene, da die Sitzung selbst die Datenebene ist.

Die Serviceebene scheint eine gültige Idee zu sein, aber nur, wenn Sie mehrere Clients für diese Ebene haben möchten.

Sonst würde ich nur 1 Projekt haben und Namespaces verwenden, um meine Schichten zu trennen. Es baut schneller und ist einfacher zu implementieren.

Quelle

2009-02-13 18:57:40

"Mit NHibernate brauchen Sie nicht wirklich eine Datenebene, da die Sitzung selbst die Datenebene ist." Um das Repository-Muster zu implementieren, abstrahiere ich die Datenebene. Auf diese Weise werden meine Dienste gegen eine Schnittstelle programmiert, und die Datenebene ist leicht austauschbar (d. H. Umschalten von O/RMs). –

Sie könnten dann Ihre Entitäten in eine Core-Bibliothek stellen und dann Ihre Repositories mit Ihren Services versehen. Repositories sind Dienste. –

Sie haben hier recht mit dem DRY-Prinzip. Ich behalte meine LINQ-to-SQL-Objekte getrennt von meinen Geschäftsobjekten und ich habe einige Duplikate und es fühlt sich nicht gut an, aber es scheint, dass es hier keine einfache Lösung gibt.

Ich hatte eine harte Zeit, diese Entscheidung treffen, aber ich sah Blog Rob Conery ist, während die MVC Storefront zu bauen und am Ende habe ich beschlossen, auf diese Weise (ORM-Objekte und Business-Objekte) gehen

Quelle

2009-02-21 12:59:14

Wo sollen meine Models wohnen? Web Tier oder Daten Tier? (MVC + NHibernate)

Antwort

Verwandte Themen