dans mon application ASP.NET MVC, j'ai une page d'édition assez complexe qui combine un certain nombre de modèles en une seule vue.
J'utilise le motif de menuLoDel pour combiner toutes ces informations et présenter un objet cohésif à la vue.
À titre d'exemple, ma structure de viewModel est quelque chose comme ceci: L'objet employé a un certain nombre de propriétés de base et a préféré Méthode de contact. sur la page Modifier, l'utilisateur reçoit tous les employés de la société et ils ont la possibilité d'ajouter et de supprimer (à l'aide de JavaScript), ainsi que de modifier les détails de l'employé. La liste ContactMethods est utilisée pour renseigner la liste déroulante pour chaque employé. J'ai traduit avec succès mes modèles (lire à partir de la base de données) dans cette vue de la vue et à nouveau, alors après une édition, je suis parti avec Mode de vue représentant l'état actuel des employés de cette société. J'utilise un motif de référentiel pour communiquer avec la base de données, donc ma question est, Devrais-je appeler directement dans le dépositaire, en passant la vue de la vue , ou devrais-je convertir la vue de la vue dans les objets modèles avant d'utiliser le référentiel pour les écrire à la base de données? en bref, Si le référentiel devrait savoir sur mes objets de viewModel? < / strong>
3 Réponses :
Je convertirai le point de vue de la vue en objets modèles en premier. J'aime garder la dépendance entre ma couche Web et les couches de référentiel aussi lâches que possible.
Je ne pense pas que votre référentiel devrait savoir sur votre viewModel, car c'est un concept de niveau Web.
Si tel est le cas (et c'est bien), je devrais créer ces modèles d'employés, supprimer tous les employés existants de cette société, puis ajouter les nouveaux modèles d'employés ... ou ... récupérer tous les modèles d'employés de la base de données et les associer avant d'ajouter, de retirer et d'éditer le cas échéant. Est-ce que ça sonne bien?
@Damovisa: Vous pourriez le faire. Au lieu de cela, je maintiendrais cette information pendant la modification. Dans votre viewModel conserve trois listes: Crééemployeurs, Editéemployeurs, Supprimer les employées.
@ Manu80 - Je vois comment cela pourrait fonctionner, mais cela pourrait être un peu compliqué. L'interface utilisateur devrait changer un peu pour tenir compte de ces trois collections - même si ce n'est que le changement de JavaScript.
@Damovisa: Vous devez gérer la complexité quelque part. Si vous allez votre route d'origine, je voudrais simplement laisser tomber tous les employés existants et ajouter les nouveaux. C'est-à-dire que s'il y a une valeur réelle ajouter de l'ajout de la complexité de votre deuxième option.
@ Manu01 - Nope, je suis d'accord avec votre première suggestion - c'est probablement la voie à suivre. Dans mon système (réel), il est parfaitement raisonnable d'effacer tous les objets de l'enfant et de les recréer.
ViewModel est le modèle à la vue (UI), donc le référentiel ne doit pas savoir sur le modèle de vue. Les séparer va garder le référentiel couplé de manière vague de l'interface utilisateur.
Utilisez une autre couche comme une couche de service, pour encapsuler le référentiel de l'interface utilisateur. Cette couche fait également la conversation de modèle de menace de vue et appelle le mode de réponse. P>
public class ServiceLayer
{
public void SaveModel(ViewModel viewmodel)
{
var model = viewModel.ToModel();
repository.Save(model)
}
}
Pourquoi faire dépendre le serviceLayer sur le point de vue? Appelez plutôt viewmodel.tomodel dans la couche de vue, puis transmettez le modèle jusqu'au service.
@ Hery - Oui, ça sonne bien, mais il y en aurait beaucoup plus que de passer un modèle au référentiel. Les modèles d'employés peuvent être nouveaux, modifiés ou supprimés.
@manu: Il s'agit simplement d'une manière différente de mettre en œuvre dépend de la manière dont vous souhaitez encapsuler votre référentiel de la vue. Mais je peux énumérer certains des avantages tels que: - Effectuer des validations commerciales qui ne sont pas couvertes par la conversion de Tomodel. - Gardez le modèle de référentiel simple et générique, tandis que la couche de service effectue des tâches plus spécifiques qui sont liées à la vue Mes 2 cents :)
Je suis d'accord avec la réponse précédente de la conversion des menuels de convertir dans des modèles "unis", mais ajouterait que cette tâche devrait probablement être effectuée par une couche de service distincte. Cette couche serait responsable du désassemblage de vos mentals de vue et d'agir correctement.
Ceci est essentiellement la définition d'un service: Quelque chose dont le travail consiste à effectuer une unité logique de travail nécessitant plusieurs modèles et / ou logique complexe.
Je pense que cet adaptation doit être séparé des contrôleurs, mais je ne pense pas non plus que cela s'adapte dans une couche totalement séparée. C'est un concept de couche de vue uniquement et devrait tomber dans des couches inférieures du tout. Vous pouvez simplement créer des adaptateurs ou un type de classe d'assistance dans la même couche que les contrôleurs / vues. Je sauverais cette couche de service (c'est entre le référentiel et la couche d'affichage) pour valider les modèles.