ASP.NET MVC: UpdateModel est-il une opération "coûteuse" (due à Reflection)?

Question

Je me demandais si UpdateModel est considéré comme une opération "coûteuse" (en raison de la recherche de Reflection des propriétés du modèle), en particulier lorsqu'elle est vue dans le contexte d'une application web plus grande (pensez à StackOverflow)? Je ne veux pas m'engager dans une optimisation prématurée, mais je considère comme un choix de conception d'utiliser UpdateModel, c'est pourquoi je voudrais savoir s'il est conseillé ou non de le faire. L'autre choix (fastidieux) consiste à écrire ma propre méthode UpdateModel pour divers objets de domaine avec des propriétés fixes.

Merci!

Answer 1

Vous êtes intelligent de vouloir ne pas se livrer à l'optimisation prématurée. D'autant plus que cette "optimisation" favoriserait le temps du processeur sur le vôtre, ce qui est beaucoup plus cher.

La règle principale de l'optimisation est d'optimiser les choses lentes en premier. Tenez compte de la fréquence à laquelle vous mettez à jour un modèle plutôt que de le sélectionner dans le backend de votre base de données. Je suppose que c'est 1/10 comme souvent ou moins. Considérons 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 à partir du backend de base de données peut être mesuré en secondes au pire. Mon expérience est que les POST sont rarement très lents, et quand ils le sont, c'est généralement la base de données qui est responsable plutôt que la réflexion. Je pense que vous passerez probablement la majeure partie de votre temps d'optimisation sur les GET.

Answer 2

Je pense que UpdateModel est un raccourci qui provoque un énorme couplage entre la vue et le modèle. Je choisis de ne pas utiliser les modèles "intégrés" (comme pouvoir passer les objets créés par LINQ à la vue directement depuis la base de données) car je veux remplacer mon modèle par quelque chose de plus sophistiqué - ou même un autre fournisseur de base de données. Il est très tentant d'utiliser LINQtoSQL (ou Entités ADO.NET) pour le prototypage rapide. Ce que j'ai tendance à faire est de créer mon application MVC, puis d'exposer une couche 'service' qui est ensuite connectée à 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 souci.

(et assurez-vous que vous écrivez vos tests et l'utilisation DI - il permet d'économiser beaucoup de tracas)

Rob

Answer 3

Comparé à la latence du réseau, aux appels de base de données et aux E/S générales, l'appel UpdateModel() est trivial et je ne m'en soucierais pas.