2010-12-14 52 views
0

Je crée une application Web MVC composée de 3 projets. Un pour l'interface graphique, un pour le BusinessLogic et un pour l'accès aux données.ASP.NET MVC - Supprimer les dépendances de DAL dans l'interface graphique

Pour mon accès aux données, j'ai un fichier généré par EF et par conséquent j'ai une classe générée nommée "Client". Pour créer des attributs de validation pour cette classe, j'ai besoin de faire MetaDataType (qui doit être fait dans le même espace de nom et donc je dois le faire dans la couche DAL) - en faisant cela je me réfère à la couche d'accès aux données de mon interface graphique ce qui gâche l'idée de scinder le projet, parce que mon interface graphique fait maintenant référence à la fois à ma couche DAL et BL. Y at-il de toute façon que je puisse séparer mes couches GUI et DAL, mais être capable d'utiliser les attributs de Validation comme [Obligatoire] et ainsi de suite?

Merci d'avance.

Répondre

2

Si vous utilisez .NET 4 (EF 2), vous pouvez générer des entités POCO dans une bibliothèque de classes séparée pouvant être partagée entre plusieurs projets. Cela ne nécessitera pas de dépendance à la DAL. Voir ma réponse précédente:

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

Surtout 3. modèles POCO, y compris la façon de passer au projet distinct: http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-poco-templates-for-the-entity-framework.aspx

+0

Comme je l'ai commenté à ma réponse, cela peut être pratique, mais il est complètement contre le concept de l'ignorance de la persistance - puisque vous mélangeriez l'interface utilisateur avec le modèle de domaine. Mais personne n'est obligé d'être un programmeur DDD, bien sûr. – rsenna

+0

@rsenna: À moins que je me trompe, vous avez toujours l'ignorance de la persistance; c'est tout l'intérêt d'utiliser POCO. Tant que vous disposez d'une autre abstraction, telle que le modèle Repository pour gérer les appels de base de données, vous pouvez remplacer l'intégralité du backend de base de données, en conservant vos entités POCO. Bien sûr, les entités POCO ne seront plus générées par EF, mais il n'y a pas de dépendance sur EF, donc cela n'a pas d'importance. –

+0

Le problème que je vois n'est pas technique mais architectural - vous partagez les ** mêmes ** entités à travers DAL et UI. Donc la présentation est couplée aux mêmes entités qui sont utilisées pour la persistance - et je ne pense pas que cela puisse s'appeler "ignorance" ...Mais, encore une fois, je l'ai déjà fait et je le ferais de nouveau pour des systèmes simples, ou fortement orientés CRUD. Tout sauf que j'irais avec viewmodels pour l'interface utilisateur, et les entités de domaine pour les couches d'entreprise et d'accès aux données. – rsenna

2

Voilà à quoi ressemble ViewModels. Mais cela signifie que vous aurez un nouvel ensemble de DTO pour la communication vue-contrôleur ... Ce qui est une bonne chose à mon humble avis, puisque vos opinions ne devraient rien savoir sur le modèle de domaine réel.

En ce qui concerne toutes les manières distinctes de faire communiquer vos vues avec le modèle, veuillez regarder this.

+0

Ces « ViewModels » - devraient-ils être transmis à ma couche BL et « enveloppé » dans l'EF a généré des classes? – ebb

+0

Non, viewmodels ne doit être vu que par les vues et les contrôleurs - ils ne font pas ** partie de votre BL ou DAL. Considérez-les comme des données que le ** utilisateur ** voit - ce qui est probablement très différent de la façon dont les mêmes données sont conservées dans votre modèle de domaine. – rsenna

+0

Que faire si je veux passer un de mes viewmodels au BL? - Ou peut-être n'utilisez-vous normalement pas de classes en paramètre? – ebb