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.
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
@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. –
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