ASP.NET MVC：UpdateModel 是“昂贵”的吗？ 操作（由于反射）？
我想知道 UpdateModel 是否被认为是“昂贵”的操作（由于模型属性的反射查找），尤其是在较大的 Web 应用程序的上下文中（想想 StackOverflow）？
我不想进行过早的优化，但我认为使用 UpdateModel 是一种设计选择，这就是为什么我想尽早知道是否建议使用它。 另一个（乏味的）选择是为具有固定属性的各种域对象编写我自己的 UpdateModel 方法。
谢谢你！
I wondered whether UpdateModel is considered an "expensive" operation (due to Reflection lookup of the model properties), especially when seen in the context of a larger web application (think StackOverflow)?
I don't want to engage in premature optimization but I consider it a design choice to use UpdateModel which is why I'd like to know early whether it is advisable or not to go with it. The other (tedious) choice is writing my own UpdateModel method for various domain objects with fixed properties.
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您很聪明，不想进行过早的优化。 特别是因为这种“优化”将有利于处理器的时间而不是你的时间，而你的时间要昂贵得多。
优化的主要规则是首先优化慢的东西。 因此，请考虑实际更新模型的频率与从数据库后端进行选择的频率。 我猜它的频率是 1/10 或更少。 现在考虑从数据库后端选择的成本与反射的成本。 反射的成本以毫秒为单位。 从数据库后端进行选择的成本最差可以以秒为单位来衡量。 我的经验是，POST 很少很慢，如果很慢，通常是数据库出错，而不是反射出错。 我认为您可能会将大部分优化时间花在 GET 上。
You are smart to want to not engage in premature optimization. Especially since this "optimization" would favor the processor's time over yours, which is far more expensive.
The primary rule of optimization is to optimize the slow stuff first. So consider how often you actually update a model versus selecting from your database backend. I'm guessing it's 1/10 as often or less. Now consider the cost of selecting from the database backend versus the cost of reflection. The cost of reflection is measured in milliseconds. The cost of selecting from the database backend can be measured in seconds at worst. My experience is that POSTs are rarely very slow, and when they are it's usually the database at fault rather than the reflection. I think you're likely to spend most of your optimization time on GETs.
与网络延迟、数据库调用和一般 IO 相比，UpdateModel() 调用微不足道，我不会为此烦恼。
Compared to network latency, database calls and general IO, the UpdateModel() call is trivial and I wouldn't bother with it.
我认为 UpdateModel 是一种捷径，会导致视图和模型之间产生大量耦合。
我选择不使用“内置”模型（例如能够将 LINQ 创建的对象直接从数据库传递到视图），因为我希望可以选择用更复杂的东西替换我的模型 - 甚至只是另一个数据库提供程序。 不过，使用 LINQtoSQL（或 ADO.NET 实体）进行快速原型设计非常诱人。
我倾向于做的是创建我的 MVC 应用程序，然后公开一个“服务”层，然后将其连接到“模型”（这是我的域的 OO 视图）。 这样我就可以轻松创建 Web 服务层、交换数据库、编写新的工作流程等，而无需担心。
（并确保编写测试并使用 DI - 这样可以省去很多麻烦！）
Rob
I think UpdateModel is a bit of a shortcut that causes a huge amount of coupling between the view and the model.
I choose not to use "built-in" models (like being able to pass LINQ created objects to the view directly from the database) because I want the option to replace my model with something more sophisticated - or even just another database provider. It is very tempting to use LINQtoSQL (or ADO.NET Entities) for fast prototyping though.
What I tend to do is create my MVC application, then expose a 'service' layer which is then connected to a 'model' (which is an OO view of my domain). That way I can easily create a web service layer, swap databases, write new workflows etc without concern.
(and make sure you write your tests and use DI - it saves a lot of hassle!)
Rob