Où mes modèles devraient vivre? niveau Web ou de niveau de données? (MVC + NHibernate)

Question

Je vais mettre en place une application n-tier avec MVC, Ninject et NHibernate (ma première utilisation de ces technologies). Par souci de clarté, les niveaux sont un niveau de niveau « données », un « Services » de niveau, et un « Web » (tous sont des projets distincts).

Avec MVC, vous avez vos modèles qui sont dans le dossier « Modèles ». Il semble nécessaire de mettre mes modèles ici pour créer des vues fortement typées et de maintenir en général avec la philosophie de MVC.

Cependant, avec NHibernate, je dois aussi mes modèles dans le niveau « données » pour que la cartographie peut avoir lieu et que NHibernate peut instancier des objets réels pour revenir à la couche de services.

Duplication les classes à travers les projets ne sont pas très sec et les abstraire dans leur propre bibliothèque ne semble pas jouer bien avec MVC (ni dans la pratique ni la philosophie).

Toutes les pensées? Comment structurer votre O / RM objets vs modèles MVC?

Answer 1

Je garde les modèles Entity Framework / classes dans le niveau de données et d'utiliser le dossier Modèles du projet MVC pour les modèles de présentation et classeurs modèles.

Answer 2

Le modèle de données est sa propre chose. Le modèle dans MVC est quelque chose de différent. Il est le modèle de ce que vous allez afficher, ce qui peut ou ne peut pas être votre modèle de données. Vous êtes modèle de données peut transcender les couches, ou non.
Prenons par exemple le formulaire d'inscription standard. Le modèle de données peut inclure le nom d'utilisateur, mot de passe et un éventail de cours d'histoire de connexion, un drapeau indiquant qu'il est d'autres choses actives et bien. Le modèle MVC, ne peut vraiment se soucier de nom d'utilisateur et mot de passe, et que l'utilisateur le mot de passe deux fois. Est-ce que votre modèle de données vraiment besoin de deux champs de mot de passe? Non, mais le modèle dans le MVC fait. Par conséquent, deux bestioles différentes.

Answer 3

Je garde tous mes modèles dans la couche de données en raison de NHibernate. Jetez un oeil à S # arp architecture un excellent moyen de garder votre propre présentation . Les modèles ne doivent pas être physiquement situé dans votre projet web pour votre point de vue à fortement typés.

Answer 4

Vous avez raison sur le principe DRY ici. Je garde mes objets LINQ to SQL séparé de mes objets métier et j'ai une certaine duplication et il ne fait pas me sentir bien, mais il semble qu'il n'y ait pas de solution simple ce ..

J'ai eu un moment difficile de prendre cette décision, mais je l'ai regardé le blog de Rob Conery pendant la construction du MVC Storefront et à la fin je décide d'aller de cette façon (objets ORM et des objets d'affaires)

Answer 5

  

Avec MVC, vous avez vos modèles   sont dans le dossier « Modèles ». Il semble   nécessaire de mettre mes modèles ici pour   créer des vues fortement typées et à   généralement garder la philosophie de   MVC.

Aucun modèle ne peut être tout ce que vous voulez. Je continue à utiliser un modèle de présentation si elle était nécessaire, mais je n'ai pas d'objection à l'utilisation de vos entités NHibernate dans vos vues.

Avec NHibernate vous ne vraiment pas besoin d'un niveau de données depuis la session elle-même est le niveau de données.

Le niveau de service semble être une idée valable, mais seulement si vous prévoyez d'avoir plusieurs clients pour cette couche.

Dans le cas contraire, je n'aurais 1 namespaces projet et d'utiliser pour séparer mes couches. Il construit plus rapidement et est plus facile à déployer.