我在C#和Razor中有一个ASP.NET MVC3。应用程序的体系结构分为数据访问层（EF类+存储库）、服务层、控制器、ViewModels和View。
我的应用程序是一个仪表板，它必须使用图形显示有关产品的统计信息。
假设我有Product和ProductCategory表，并且在图中，我必须显示每月售出的Products和ProductCategory的百分比。在x轴上我有月份，在y轴上是百分比ProductPerCategory/ProductTotal，因此我有与ProductCategories一样多的行。
在这种情况下，我的域模型是由EF上的Product和ProductCategory对象创建的。我的存储库将这些域对象提供给它的上层（服务层）。
我的业务模型是由ProductGraph对象创建的，我的服务层将此业务对象提供给它的上层（控制器）。
我的控制器获取此ProductGraph对象，并将其映射到视图中要显示的视图模型ProductGraphViewModel。
模型之间的这种区别正确吗？在层之间传递的对象的定义上是否存在任何不足或糟糕的方法？
我会问一些我自己的问题来回答你的问题。
-
"领域模型"one_answers"业务模型"之间的区别是什么？每一个都比另一个更有价值吗？如果不了解更多，我会认为它们是一样的。
-
您的服务层有什么好处？人们（包括我自己）经常陷入"服务层"陷阱，而实际上它只是包装了您的Repository方法。您最终会将ORM细节泄露到消费层，从而从一开始就破坏了抽象的要点。
如果您给我们一些层之间示例流的代码，这可能会有所帮助。
是的，@sweaver2112在使用DI方面很到位。设置简单，效益最大。
好吧，我的外行对你竖起大拇指，这似乎很标准。其他一些需要考虑的问题是：1）您的DAL/服务层是否接口？以及2）您是否使用依赖注入（将这些接口传递给控制器实例化）？通过这种方式，您可以轻松地切换实现，或者模拟单元测试。
这篇博文可能很有意思。