Nous avons eu une discussion au travail sur l'utilisation d'objets de domaine dans nos vues (ASP.NET MVC 2) ou si chaque point de vue nécessitait des données nécessitant une vue de vue?
Je me demandais si quelqu'un avait des avantages / contre sur ce sujet qu'ils pouvaient éclairer une lumière sur?
merci
5 Réponses :
Si vous utilisez NHibernate ou similaire - vos objets de domaine seront probablement des procurations, sérialisant ces travaux de DUN. Vous devez toujours utiliser un point de vue et mapper vos objets de domaine vers DTO dans votre viewModel. Ne prenez pas de raccourcis ici. Établir la convention atténuera la douleur que vous subirez plus tard.
C'est un modèle standard pour une raison.
w: //
J'aime séparer mes objets de domaine de mes vues. En ce qui me concerne, mes objets de domaine sont uniquement dans le but de représenter le domaine de l'application, maintenant la manière dont l'application est affichée.
La couche de présentation ne doit contenir aucune logique de domaine. Tout ce qu'ils affichent doit être prédéterminé par leur contrôleur. Le moyen idéal de s'assurer que cela est toujours respecté est de veiller à ce que la vue ne reçoit que ces menuels aplaties.
J'ai demandé à un Question similaire < / a> moi-même. Voici une citation de la réponse que j'ai acceptée:
Je pense qu'il y a des mérites à
avoir un design différent dans le
domaine que dans la couche de présentation.
Si conceptuellement vous êtes en fait
En regardant deux modèles différents, un
pour la couche de domaine et un pour le
couche de présentation. chacun des modèles
est optimisé pour leur but .
Si j'ai les objets de domaine pour Aussi, pourquoi voudriez-vous passer un objet de domaine entier à une vue si vous pouvez créer une représentation optimisée de ce modèle?
client > ventes > adresse d'expédition , alors je ne veux pas avoir à gérer le Objet Traversal à mon avis. Je crée un modèle de vue aplatie contenant toutes les propriétés. Il n'y a presque pas de travail supplémentaire dans la cartographie de ce modèle de visualisation / présentation aplatie si vous utilisez l'excellent projet Open Source Automapper .
+1, mais qu'en est-il des objets de domaine simples, comme une catégorie, qui a juste un identifiant et une étiquette? Pour certaines applications avec beaucoup de ceux-ci, il peut devenir assez gênant de créer une myentity {id, label} et myDTo {id, label}, où la seule chose différente est le nom.
@Mathieu - Évidemment, vous pouvez utiliser votre discrétion quand il s'agit d'exemples comme celui-ci :). Des objets de domaine tels que votre exemple ne contiendraient aucune logique de domaine et il serait certainement acceptable.
Ok c'est ce que je pensais. Si vous avez un peu de temps, vous pourriez avoir un coup d'oeil à celui-ci: Stackoverflow.com/Questtions/3539108/... ? Je ne suis pas vraiment neuf avec les trucs techniques ASP.NET MVC, mais pour le "philosophique" et la conception, je pourrais utiliser certains pointeurs!
Il pourrait y avoir «presque pas de travail supplémentaire» dans la cartographie / des modèles aplaties, mais il est certain que vous travaillez également dans la création et la maintenance de 2 (voire 3, dans le cas de modèles d'entités distincts). Il est facile de voir pourquoi la question de "Puis-je m'éloigner de la séparation et de la cartographie du modèle?" continue à venir. Je souhaite vraiment qu'il y ait un moyen, franchement. En pratique, pour des applications simples, la création d'une série de modèles de vue et de mappage vers / depuis les modèles de domaine est beaucoup de redondance inutile.
Cela dépend. Dans certains cas, tout ira bien d'utiliser des instances de classes de modèle. Dans d'autres cas, une vue de vue distincte est le meilleur choix. D'après mon expérience, il est parfaitement acceptable d'avoir des modèles différents dans votre domaine et de votre point de vue. Ou d'utiliser le modèle de domaine dans la vue. Faites ce qui fonctionne mieux pour vous. Faites une pointe pour chaque option, voir ce qui fonctionne, puis décidez. Vous pouvez même choisir une option différente pour chaque vue (et / ou partielle).
Il y a définitivement des petites applications simples où il convient d'utiliser les mêmes modèles sur toutes les couches. Généralement peu de formes sur les applications de données. Mais pour un domaine approprié, mes réflexions sur le sujet sont de conserver les modèles de domaine et de voir des modèles séparés car vous ne voulez pas qu'ils se soient jamais s'imcidents quand ils ont changé.
Si la logique de domaine nécessite un petit changement pour traiter une nouvelle logique commerciale à l'arrière, vous ne voulez pas risquer de modifier votre vue. Inversement, si le marketing ou si quelqu'un veut apporter des modifications à une vue, vous ne voulez pas que ces changements se rentrent dans votre domaine (devoir remplir des champs et entretenir des données sans autre objectif que certaines vision quelque part pour l'utiliser). < / p>
J'ai une bonne comparaison actuellement parce que je travaille sur deux projets en utilisant différentes approches. Je suis loin d'indiquer que "c'est mauvais et c'est bon" parce que cela est écrit dans certains modèles. Je connais des modèles, j'aime les motifs, mais je ne les suivis jamais aveuglément juste pour avoir raison. J'utilise toujours ce que j'ai besoin actuellement pour atteindre les objectifs actuels.
Dans la première application, à l'aide d'objets de domaine en vue, le développement est très rapide. Peu de changements dans quelques endroits et vous avez des propriétés supplémentaires, forment des entrées de formulaire, etc. Vous ne vous inquiétez pas des couches, ne prolonge pas / changez le code et passez à un autre problème.
Dans la deuxième application, où il y a toujours un objet à utiliser ici, là-bas et ailleurs, il y a une dizaine de cours à la lumière, de la même chose et d'une tonne de code de conversion entre différentes versions des mêmes objets. Plus mauvais est que certains développeurs font une logique sur "cette version" de la classe et une autre logique se fait sur "cette version". Le développement est très douloureux et nécessite beaucoup de tests après. Changer une chose simple nécessite beaucoup d'attention et beaucoup de code doivent être modifiés. Je n'aime vraiment pas cette application pour cela, car je n'ai jamais encore vu d'avantages commerciaux de cette approche, du moins au cours de l'année dernière (et nous sommes dans le stade de la production de l'année). Cette application est trois-quatre fois plus chère pour développer et entretenir que le premier.
Alors, ma réponse amusante sur la question est la suivante: cela dépend. Si vous travaillez dans 10-20 personnes, vous aimez entrer dans le travail, boire peu de cafés, parler avec un ami, faire quelques choses simples et rentrer à la maison, beaucoup d'objets intermédiaires et de code de conversion seront bons pour vous. Si votre objectif est d'être rapide et bon marché, si vous souhaitez vous concentrer sur la couche d'entreprise, de nouvelles fonctionnalités, des modifications rapides suivantes, etc. Si vous touchez les entreprises du logiciel et que vous souhaitez encaisser votre projet (nous faisons toutes ces choses à être enfin vendues, droite?), la deuxième approche serait probablement meilleure.