Asp.net MVC Architecture

Question

J'arrive à la fin de mon premier projet MVC, et je ne suis pas très satisfait de la façon dont j'ai construit mes objets Model et je cherche des idées pour les améliorer.

J'utilise des référentiels pour chaque table DB avec les méthodes Get, Save, Delete etc. Les référentiels utilisent Linq2Sql pour l'accès à la base de données.

Je fais le mappage des objets Linq2Sql vers les objets MVC Model, dans la plupart des cas, il s'agit de 1 à 1 mappages. Mon problème est, je ne pense pas que mes objets de modèle MVC étaient assez granulaires, et je transmets probablement plus de données que nécessaire.

Par exemple, j'ai une table utilisateur. Un administrateur peut éditer les détails d'un utilisateur tout comme l'utilisateur lui-même, donc je pense que je devrais vraiment avoir un objet "AdminUserModel" et "UserModel", où "AdminUserModel" a un plus grand nombre de valeurs (IsEnabled par exemple). Donc, ma plus grande question est: quel genre d'architectures les gens utilisent-ils dans la nature, afin de cartographier de nombreux objets Model similaires à travers les couches à la DB?

Des exemples de solutions d'architecture que n'importe qui peut proposer au-delà de NerdDinner?

merci d'avance!

Answer 1

Dans le cas de votre modèle utilisateur, vous devez utiliser l'héritage au lieu de 2 modèles séparés. De cette façon, vous pouvez utiliser le code qui a été créé pour l'utilisateur dans ceux qui en héritent. Le type de modèle que vous utilisez dépend entièrement de ce que vous voulez en faire. Une bonne chose pourrait être de regarder les modèles et essayer de faire fonctionner les modèles qui sont nécessaires pour votre situation ...

Answer 2

Je prends habituellement l'héritage d'un outil dans mes modèles. J'ai généralement une classe de base d'entité, qui aura id, datecreated, valide et tous les autres champs qui sont partagés entre les entités (publishStatus, verrouillé etc). En cas de besoin, vous pouvez créer d'autres classes de base héritant de l'entité: entité personne, entité produit, etc.

cette façon, vous pouvez avoir une base du référentiel générique, contraint à Entity ou IEntity, je trouve que la plupart des entités fonctions CRUD ne avez pas besoin un comportement bien plus que celle fournie par la base générique (peut-être vous devrez ajouter quelques méthodes get supplémentaires pour certains types)

Dans votre cas, AdminUser pourrait hériter de User