如何扩展 ASP.NET MVC 和实体框架中的模型？
在我的第一个 ASP.NET MVC 应用程序中，模型是表和类之间的简单 O/R 映射，由实体框架管理。
现在我想向这个骨架添加一些内容，并为生成的类引入业务方法。 ASP.NET MVC（使用实体框架）中推荐的方法是什么？我最喜欢的是也可以在服务层中使用的解决方案，无需 ASP.NET MVC 引用，因此相同的域逻辑也可以在桌面客户端中重用。
从技术上讲，我认为应该可以以保留额外业务逻辑的方式扩展生成的类，即使 O/R 类需要刷新也是如此。 （然而，这更多是与实体框架相关的问题。）
编辑：非常感谢您的贡献以及有关下一版本实体框架（4.0）的信息。构建两组类，一组自动生成以表示持久层中的数据，一组用于实际业务逻辑，这听起来很有趣。
In my first ASP.NET MVC applications, the model was a simple O/R mapping between a table and the classes, managed by the Entity Framework.
Now I would like to add some meat to this skeleton, and introduce business methods for the generated classes. What is the recommended approch to this in ASP.NET MVC (with Entity Framework)? My favorite would be solution which also can be used in a service layer, with no ASP.NET MVC references, so that the same domain logic also could be reused in a desktop client.
Technically, I think it should be possible to extend the generated classes in a way which preserves the additional business logic even if the O/R classes need to be refreshed. (This is more a question related to the Entity Framework however.)
Edit: Many thanks for the contributions, and the information about the next version of Entity Framework (4.0). Building two sets of classes, one auto-generated to represent the data in the persistency layer and one for the actual business logic sounds interesting.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在 MVC.Net 中，模型是定义最不明确的部分。在我看来，它基本上是应用程序的其余部分（即与视图或控制器无关的任何内容）。应用程序的 O/R 映射部分可能也应该位于“模型”之外，因为这更多的是数据层。模型应该真正处理业务对象并创建数据视图以传递给视图。
对此有很多不同的意见，但我认为最好不要将 MVC.Net 视为传统的 MVC 架构。
Within MVC.Net, the model is the least clearly defined part. In my opinion, it's basically the rest of your application (i.e. anything not related to the View or the Controller). The O/R Mapping part of your application should probably be outside of the "Model" also, as this is more of a data layer. The Model, should really deal in business objects and create views of your data to pass to the View.
There are lots of differing opinions on this, but I think it's best not to think of MVC.Net as traditional MVC Architecture.
如果您现在使用 EF v1.0，实体框架对您的应用程序的侵入非常大，这意味着您无法非常轻松地创建 POCO。扩展模型的方法是使用分部类。因此，当您刷新模型时，您所做的部分类仍然有效。实体框架团队意识到这是一个问题，并在下一版本（EF V4.0）中对此进行了改进。
NHibernate 更加友好，可以让您轻松扩展业务逻辑。
我真的认为这个博客Jeremy D. Miller 的帖子非常善于指出问题。
If you are using EF v1.0 right now, the Entity Framework is very intrusive into your application, which means that you cannot create POCO very easily. The way you can extend your model is by using the partial class. So when you refresh your model, the partial class you did will still be valid. The Entity Framework team realizes this is a problem , and have improved this in next version (EF V4.0).
NHibernate is much more friendly and allow you easily extend your business logic.
I really think this blog post by Jeremy D. Miller is very good at pointing out the problem.
将您的业务层抽象到另一个项目中，然后使用结构图之类的东西将其实例传递到您的 mvc 控制器上。然后，您可以从控制器调用此业务层来检索业务实体（模型）并将它们传递到 UI。这将允许您在桌面应用程序中重复使用业务层。
Abstract your Business Layer out into another project, then pass an instance of it onto your mvc controller using something like structure map. You can then call this Business Layer from your controller to retrieve your business entities (Model) and pass them on to the UI. This will allow you to resuse your Business Layer in your desktop application.
不仅是肉，还可以添加一些衣服和风格到这个项目中，使其看起来别致。这取决于您用于该项目的时间。如果你有时间，我建议你看看 TDD 以及可以与 TDD 一起使用的框架，例如 Castle、NUnit、Moq 等。
正如你提到的，服务层对于任何项目来说都是必须的，但是对于这些类型的项目来说，服务层是必须的。框架，您可以将架构设计得更加健壮。
Not only meat but also some clothes and a style could be added to this project to make it seem chic. It depends on the time you have for the project. If you have time, I could suggest you to get a look to TDD and the frameworks that could be used with TDD such as Castle, NUnit, Moq etc.
As you mentioned a service layer is a must for any project but with these kinds of frameworks you could design your architecture more robust.