Wo sollte sich meine Modelle leben? Web-Tier-oder Daten-Tier? (MVC + NHibernate)

Question

Ich gründe eine n-Tier-Anwendung mit MVC, Ninject auf und NHibernate (meine erste Einsatz dieser Technologien). Aus Gründen der Klarheit willen sind die Ebene ein „Data“ Tier, ein „Service“ Tier und ein „Web“ Tier (alle sind separate Projekte).

Mit MVC haben Sie Ihre Modelle, die in der "Models" Ordner befinden. Es erscheint notwendig, meine Modelle hier setzt stark typisierte Ansichten zu erstellen und in der Regel mit der Philosophie von MVC zu halten.

Doch mit NHibernate, ich brauche auch meine Modelle in der „Data“ Tier so dass die Zuordnung stattfinden kann und dass NHibernate können die tatsächlichen Objekte instanziiert an die Diensteschicht zurückzukehren.

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

Alle Gedanken? Wie strukturieren Sie Ihre O / RM-Objekte vs MVC-Modelle?

Answer 1

Ich halte Entity Framework Modelle / Klassen in der Datenebene und verwenden Sie die Ordner Modelle des MVC-Projektes für die Präsentation Modelle und Modell Bindemittel.

Answer 2

Das Datenmodell ist es Sache ist. Das Modell in MVC ist etwas anderes. Es ist das Modell von dem, was Sie anzeigen gehen, das Ihr sein kann oder auch nicht-Datenmodell. Sie sind Datenmodell Schichten überschreiten kann, oder nicht.
Nehmen wir zum Beispiel die Standard-Anmeldeformular. Das Datenmodell kann den Benutzername, ein Passwort und eine Reihe von Login Geschichte Klassen umfasst, ein Flag, das angibt, es ist aktiv und viele andere Sachen. Das Modell in MVC, kann über Benutzername und Passwort nur wirklich interessieren, und dass der Benutzer das Passwort zweimal eingeben. Hat Ihr Datenmodell wirklich braucht zwei Passwort-Felder? Nein, aber das Modell in der MVC tut. Daher werden zwei verschiedene Lebewesen.

Answer 3

Ich halte alle meine Modelle in der Datenebene wegen NHibernate. Schauen Sie sich auf S # arp Architektur für eine gute Möglichkeit, Ihre Präsentation sauber zu halten . Alle Modelle haben nicht physisch in Ihrem Web-Projekt lokalisiert werden für Ihre Ansichten stark typisiert werden.

Answer 4

Sie haben Recht, über das DRY-Prinzip hier. Ich halte meine LINQ-to-SQL-Objekte von meinen Business-Objekten getrennt, und ich habe einige Überschneidungen und es mich nicht gut fühlen, aber es scheint, dass es keine einfache Abhilfe ist ..

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

Answer 5

  

Mit MVC haben Sie Ihre Modelle, die   in der „Models“ Ordner befinden. Es scheint   notwendig meine Modelle hier zu setzen, um   stark typisierte Ansichten erstellen und zu   im Allgemeinen hält mit der Philosophie   MVC.

Es kann kein Modell, was Sie wollen sein. 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 Sie nicht wirklich brauchen eine Datenebene, da die Session selbst die Datenebene ist.

Das Service-Tier scheint eine gültige Idee, aber nur, wenn Sie planen, für diese Schicht mehr Client mit.

Ansonsten würde ich nur 1 Projekt und die Verwendung von Namespaces meiner Schichten zu trennen. Es baut schneller und ist einfacher zu implementieren.