Je me demandais si l'UpdateModel est considérée comme une opération «coûteuse» (en raison de la recherche de réflexion des propriétés du modèle), en particulier lorsqu'on l'a vu dans le contexte d'une application Web plus grande (pensez Stackoverflow)?
Je ne veux pas participer à une optimisation prématurée, mais je considère que j'en considère un choix de conception d'utiliser UpdateModel, c'est pourquoi j'aimerais savoir tôt s'il est conseillé ou non d'y aller. L'autre choix (fastidieux) écrit ma propre méthode UpdateModel pour divers objets de domaine avec des propriétés fixes.
Merci!
3 Réponses :
Je pense que UpdateModel est un peu de raccourci qui provoque une énorme quantité de couplage entre la vue et le modèle.
J'ai choisi de ne pas utiliser de modèles "intégrés" (comme être capable de passer des objets créés Linq à la vue directement dans la base de données) car je souhaite que l'option remplace mon modèle avec quelque chose de plus sophistiqué - ou même une autre base de données fournisseur. Il est très tentant d'utiliser linqtosql (ou entités ado.net) pour un prototypage rapide cependant.
Ce que j'ai tendance à faire, c'est créer mon application MVC, puis exposez un calque "Service" qui est ensuite connecté à un "modèle" (qui est une vue OO de mon domaine). De cette façon, je peux facilement créer une couche de service Web, échanger des bases de données, écrire de nouveaux flux de travail, etc. sans préoccupation.
(et assurez-vous d'écrire vos tests et d'utiliser di - ça économise beaucoup de tracas!)
rob
Je pense que le point de sa question reste le même, cependant, que vous mettez à jour les objets de domaine directement ou que vous utilisiez un modèle d'édition spécialisé (que moi aussi recommandé).
Vous êtes intelligent de vouloir ne pas vous engager dans une optimisation prématurée. Surtout que cette "optimisation" favoriserait le temps du processeur sur le vôtre, ce qui est beaucoup plus cher.
La règle principale d'optimisation consiste à optimiser les choses lentes d'abord. Considérez donc à quelle fréquence vous mettez-vous à jour un modèle par rapport à la sélection de votre backend de base de données. Je suppose que c'est 1/10 aussi souvent ou moins. Envisagez maintenant le coût de la sélection du backend de la base de données par rapport au coût de la réflexion. Le coût de la réflexion est mesuré en millisecondes. Le coût de la sélection de la backend de la base de données peut être mesuré en quelques secondes au pire. Mon expérience est que les postes sont rarement très lents et quand ils sont généralement la base de données en défaut plutôt que la réflexion. Je pense que vous êtes susceptible de passer la majeure partie de votre temps d'optimisation sur Gets.
comparé à la latence réseau, aux appels de base de données et au général IO, l'appel UpdateTemodel () est trivial et je ne me dérangerais pas avec elle.