ASP.NET MVC 模型模式：什么最有效？
我已经在 ASP.NET MVC 中完成了几个项目，但有一个主题我还没有真正在任何地方看到过。我想听听其他人对此的看法。
设计模型的最佳实践有哪些？我过去采取了两种方法：模型应该代表不同的实体，还是应该具有特定于域的（特定于子域的？特定于视图的？）模型？真正的区别在于代表不同实体的模型在多个视图中使用，因为领域特定模型与特定视图相关联。
请考虑以下事项：我的应用程序中有一个 User 实体。我应该在 Register 视图、Show 视图、Index 视图等中使用单个 UserModel，还是最好使用 RegisterUserModel、ShowUserModel、ListUserModel 等？
我以前使用过这两种模式。领域特定模型的优点是，通过属性应用的任何验证逻辑在视图之间都可以不同。缺点是你违反了 DRY 并且你的模型变得非常复杂——即使你将它们分离到命名空间中。相反，使用单一模型到实体模式会导致过于通用的验证数据（通常与错误消息有关），但您有一个漂亮、紧密的模型层，并且模型和实体之间的转换要容易得多（代码更少）。
SO 更喜欢什么方法？还是有一种我根本没有考虑过的方法？
I've done a couple of projects in ASP.NET MVC and there is a topic that I haven't really seen covered anywhere. I wanted to get some other peoples' opinions on this.
What are some best practices for designing models? I've taken two approaches in the past: Should models represent distinct entities, or should you have domain specific (sub-domain specific? view specific?) models? The difference really being models representing distinct entities are used in more than one view where as the domain specific models are tied to specific views.
Consider the following: I have a User entity in my application. Should I have a single UserModel that I use in the Register view, the Show view, the Index view, etc., or would it be preferred to have a RegisterUserModel, a ShowUserModel, a ListUserModel, etc.?
I've used both patterns before. The up side of the domain specific models is that any validation logic applied via attributes can be different between views. The down side is you violate DRY and your models get pretty hairy -- even if you separate them in to namespaces. Conversely, using the single model-to-entity pattern leads to overly generic validation data (usually with regard to error messages) but you have a nice, tight model layer and converting between models and entities is a lot easier (less code).
What approach does SO prefer? Or is there an approach that I'm not even considering?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我喜欢创建数据模型，然后根据需要创建特定的视图模型。
ViewModel 案例
ViewModel 模式
I like to create my data models and then create specific view models as I need them.
The Case for ViewModel
The ViewModel Pattern
当我想到领域模型时，我也会想到业务逻辑。我尝试在 MVC 中保留 M 来指代有助于应用程序表示方面的模型，而不是代表我的现实世界对象的实体（域对象）。
When I think of domain models, I think about business logic as well. I try to keep the M in MVC to refer to the models that assist in the presentation aspect of the application, and not the entities (domain objects) that represent my real-world objects.
模型和视图应该是一对。构建巨大的模型类和巨大的视图并不是一个好主意。在我看来，在您的视图模型中，您应该只表示业务逻辑所需的部分。例如。创建注册表单时，使模型和视图尽可能简单 - 创建
RegisterUserModel.cs和RegisterUserView.aspx。不要将整个 User 对象传递给那里。让它变得轻松，不要违反单一责任原则。Model and View shuld be a pair. Building huge Model classes and huge Views is not good idea. In my opinion in your view-Model you should represent only needed part of your business logic. For example. When you'r creating Registration form make your Model and View that simple as it can be possible - Create
RegisterUserModel.csandRegisterUserView.aspx. Do not pass there whole User object. Make it light, don't break Single Responibility Principle.