我想知道 UpdateModel 是否被认为是“昂贵的”操作（由于模型属性的反射查找），尤其是在更大的 Web 应用程序的上下文中看到时（想想 StackOverflow）？
我不想进行过早的优化，但我认为使用 UpdateModel 是一种设计选择，这就是为什么我想及早知道是否建议使用它。另一个（乏味的）选择是为具有固定属性的各种域对象编写我自己的 UpdateModel 方法。
谢谢！
问问题
637 次
3 回答
5
你很聪明，不想过早地进行优化。特别是因为这种“优化”将有利于处理器的时间而不是你的时间，这要昂贵得多。
优化的主要规则是首先优化慢的东西。因此，请考虑您实际更新模型的频率与从数据库后端选择的频率。我猜它经常是 1/10 或更少。现在考虑从数据库后端选择的成本与反射的成本。反射成本以毫秒为单位。从数据库后端进行选择的成本最多可以以秒为单位来衡量。我的经验是 POST 很少很慢，当它们出现时，通常是数据库出错而不是反射。我认为您可能会将大部分优化时间花在 GET 上。
于 2009-07-30T12:45:25.710 回答
2
与网络延迟、数据库调用和一般 IO 相比，UpdateModel() 调用是微不足道的，我不会打扰它。
于 2009-07-30T12:59:26.700 回答
0
我认为 UpdateModel 是一种捷径，会导致视图和模型之间存在大量耦合。
我选择不使用“内置”模型（例如能够将 LINQ 创建的对象直接从数据库传递到视图），因为我希望可以选择用更复杂的东西替换我的模型 - 甚至只是另一个数据库提供程序。不过，使用 LINQtoSQL（或 ADO.NET 实体）进行快速原型制作非常诱人。
我倾向于创建我的 MVC 应用程序，然后公开一个“服务”层，然后将其连接到一个“模型”（这是我的域的 OO 视图）。这样我就可以轻松地创建 Web 服务层、交换数据库、编写新的工作流等，而无需担心。
（并确保您编写测试并使用 DI - 它节省了很多麻烦！）
抢
于 2009-07-30T08:00:56.320 回答