MVC 分层应用程序中业务、域和视图模型的正确定义和设计
我有一个 C# 和 Razor 中的 ASP.NET MVC3。应用程序的架构分为数据访问层（EF 类 + 存储库）、服务层、控制器、视图模型和视图。
我的应用程序是一个仪表板，它必须使用图表来显示有关产品的统计信息。
假设我有 Product 和 ProductCategory 表，并且在图表中我必须显示每个 ProductCategory 的已售出 Products 的百分比每月。在 x 轴上有月份，在 y 轴上有百分比 ProductPerCategory/ProductTotal，因此我有与 ProductCategories 一样多的行。
在本例中，我的域模型是由EF上的Product和ProductCategory对象创建的。我的存储库将这些域对象提供给其上层（服务层）。
我的业务模型是由ProductGraph对象创建的，我的服务层将该业务对象提供给其上层（控制器）。
我的控制器获取此 ProductGraph 对象并将其映射到要在视图中显示的 View Model ProductGraphViewModel。
模型之间的这种区别正确吗？在层间传递的对象的定义上是否有任何不足或不好的方法？
I have an ASP.NET MVC3 in C# and Razor. The architecture of the application is divided in Data Access Layer (EF classes + Repository), Service Layer, Controller, ViewModels and View.
My application is a dashboard, it has to display statistics about products by using graphs.
Assume I have Product and ProductCategory tables and in a graph I have to display the percentage of sold Products per ProductCategory per Month. In the x-axis I have the months, in the y-axis the percentage ProductPerCategory/ProductTotal and therefore I have as many lines as ProductCategories.
In this case my Domain Model is made by Product and ProductCategory objects on the EF. My repository gives these domain objects to its upper layer (Service Layer).
My Business Model is made by the ProductGraph object and my Service Layer gives this business object to its upper layer (Controller).
My controller take this ProductGraphobject and map it to the View Model ProductGraphViewModel to be displayed in the view.
Is this distinction between models correct? Is there any shortfall or bad approach on the definition of the objects passed between layers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会通过问我自己的一些问题来回答你的问题。
“领域模型”和“业务模型”之间有何区别？每一个都比另一个提供更多/更少的价值吗？如果不了解更多，我会假设它们是同一件事。
您的服务层有什么好处？人们（包括我自己）经常陷入“服务层”陷阱，而实际上它只是包装了您的存储库方法。您最终会将 ORM 细节泄露给消费层，从而从一开始就破坏了您的抽象点。
如果您为我们提供一些层之间示例流程的代码可能会有所帮助。
是的，@sweaver2112 在使用 DI 方面非常到位。设置简单，效益最大化。
I'll answer your question by asking a few of my own.
What is your distinction between "Domain Model" and "Business Model"? Do each give more/less value than the other? Without knowing more, i would assume they are the same thing.
What benefit does your Service layer give? People (myself included) have often fallen into the "Service layer" trap, when in fact it just wraps your Repository methods. You end up leaking ORM specifics to consuming layers, defeating the point of your abstraction in the first place.
It might help if you give us some code of an example flow between the layers.
And yes, @sweaver2112 is spot on about using DI. Simple setup, maximum benefit.
嗯，我的外行人都竖起了大拇指，这看起来很标准。其他需要考虑的事项包括：1) 您的 DAL/服务层是否有接口？ 2）您是否使用依赖注入（将这些接口传递给控制器实例化）？这样您就可以轻松切换实现或模拟单元测试。
此博客文章可能会引起兴趣。
Well, you have my layman's thumbs up, this seems pretty standard. Some other things to consider are: 1) is your DAL/Service Layer interfaced? and 2) are you using dependency injection (passing these interfaces to the controller instantiation)? That way you can switch out implementations, or mock for unit tests easily.
This blog post might be of interest.