Renvoi de POCOs spécifiquement formés aux actions ASP.NET MVC

Question

Dans mon projet ASP.NET MVC, mes actions appellent généralement une couche de service pour obtenir des données. J'utilise la même douzaine de POCOs pour tous mes modèles. Je prévois également d'utiliser la couche Service dans les applications console et peut-être d'exposer une api web à un moment donné.

Pour rendre les opérations de ma base de données plus efficaces, ma couche de service n'hydrate que les propriétés du modèle qui sont pertinentes pour la méthode particulière (qui, à ce stade, est principalement déterminée par les besoins des actions de mon contrôleur).

Ainsi, par exemple, je pourrais avoir une classe Order avec des propriétés Id, Name, Description, Amount, Items . Pour un appel de service donné, il se peut que je n'aie besoin de remplir que les champs suivants Id, Name, Items . Un consommateur de ce service ne saura pas nécessairement que Amount est 0 uniquement parce qu'il n'a pas rempli la propriété.

De même, le consommateur ne saura pas si Items est vide parce qu'il n'y a en fait aucun élément, ou si cette méthode de service particulière ne remplit tout simplement pas cette propriété.

Et pour un troisième exemple, disons que l'une de mes vues affiche une ItemCount . Je ne veux pas remplir entièrement mon site Web. Items j'ai juste besoin d'une propriété supplémentaire sur mon "modèle". Je ne veux pas ajouter cette propriété à mon POCO que les autres méthodes de service utiliseront, car elle ne sera pas remplie ailleurs.

La solution naturelle est donc de créer une POCO conçue spécifiquement pour cette méthode, avec uniquement ces 3 propriétés. De cette façon, le consommateur peut savoir que toutes les propriétés seront remplies avec leurs valeurs réelles. L'inconvénient de cette solution est que je vais finir par écrire des tonnes de modèles de forme similaire.

Des conseils sur la méthode la plus efficace ?

Answer 1

Je suggère qu'au lieu de modifier les modèles ou de créer des modèles enveloppants, vous devez nommer les méthodes du service de manière à ce qu'elles soient explicites. et révèle au consommateur ce qu'il retourne.

Le problème avec l'approche nullable est qu'elle donne à l'utilisateur l'impression que le bien n'est pas requis ou obligatoire et ils essaient d'insérer des instances de ces types sans définir ces propriétés. Est-ce que ce ne sera pas mauvais d'avoir des nullables partout ?

Ce n'est pas une bonne approche de changer les modèles de domaine puisque tout ce que vous voulez, c'est simplement remplir certaines des propriétés. Au lieu de cela, vous créez des services avec des noms et des descriptions qui sont auto-explicatifs.

Prenez le Order en tant qu'exemple, disons qu'une méthode de service renvoie l'information suivante Order avec tous les éléments et l'autre renvoie uniquement les détails de l'article. Order mais pas les articles. Dans ce cas, il est évident que vous devrez créer deux méthodes de service GetOrderItems y GetOrderDetail Mais remarquez que le nom des méthodes du service indique au client ce qu'il va retourner. Dans le GetOrderDetail vous pouvez retourner un élément vide ou null (mais ici je suggère un null) cela n'a pas beaucoup d'importance.

Ainsi, pour les nouveaux cas, vous n'avez pas besoin de modifier fréquemment les modèles, mais il vous suffit d'ajouter ou de supprimer les méthodes du service et c'est tout. Puisque vous créez un service, vous pouvez créer une documentation solide qui indique quelle méthode fait quoi .

Answer 2

Je n'optimiserais pas trop les performances à moins que vous n'ayez de réels problèmes de performances.

Je ferais seulement une distinction entre le retour d'un objet plat et un objet avec un graphe d'objet plus complet.

J'aurais des méthodes qui renvoient des objets plats appelés par exemple GetOrder, GetProduct.

Si des graphiques d'objets plus complets sont demandés, ils seront appelés : GetOrderWithDetails.

Utilisez-vous les classes POCO pour les vues typées ? Si oui : essayez de créer de nouvelles classes qui servent de ViewModels dédiés. Ces ViewModels contiendraient des classes POCO. Cela vous aidera à garder les classes POCO propres.

Answer 3

Pour développer l'idée du nullable, vous pourriez utiliser la bibliothèque fluentvalidation pour que la validation des types dépende du fait qu'ils soient nuls ou non. Cela vous permettrait de faire en sorte qu'un champ soit obligatoire tant qu'il n'est pas nul ou tout autre schéma de validation auquel vous pouvez penser. Exemple tiré de mon propre code, car j'avais une exigence similaire :

Imports FluentValidation

Public Class ParamViewModelValidator
    Inherits AbstractValidator(Of ParamViewModel)

    Public Sub New()
        RuleFor(Function(x) x.TextBoxInput).NotEmpty.[When](Function(x) Not (IsNothing(x.TextBoxInput)))
        RuleFor(Function(x) x.DropdownListInput).NotEmpty.[When](Function(x) Not (IsNothing(x.DropdownListInput)))
    End Sub

End Class