我已经使用ASP.net MVC大约两年了，我还在学习构建应用程序的最佳方法。
我想抛弃我收集的这些想法，看看它们是否是社区设计MVC应用程序的“可接受”方式。
这是我的基本布局：
DataAccess项目 - 包含非MS SQL数据库存储库的所有存储库类，LINQ-to-SQL数据上下文，过滤器和自定义业务对象（LINQ-to-SQL不支持不创造。存储库通常只有他们正在管理的对象的基本CRUD。
服务项目 - 包含执行业务逻辑的服务类。他们接受控制器的命令并告诉存储库要做什么。
UI项目 - 包含视图模型和一些包装器，如ConfigurationManager（用于单元测试）。
主要MVC项目 - 包含控制器和视图，以及javascript和css。
这似乎是构建ASP.NET MVC 2应用程序的好方法吗？还有其他想法或建议吗？
视图模型是否用于视图的所有输出和视图输入？
我倾向于为每个需要在视图中显示数据的业务对象创建视图模型，并使它们成为具有一系列属性的基本类。这使得处理视图变得非常容易。然后，服务层需要管理从视图模型到业务对象的映射属性。这是我的一些困惑的原因，因为我在MVC / MVC2上看到的大多数示例都不使用视图模型，除非你需要像组合框这样的东西。
如果您使用MVC 2的新模型验证，那么您是否会验证viewmodel对象而不必担心将验证属性放在业务对象上？
如何对这种类型的验证进行单元测试，或者我不应该单元测试是否返回了验证消息？
谢谢！
答案 0 :(得分：2)
有趣。
我做的一件事就是我从我的Domain项目中拆分了DataAccess项目。域项目仍然包含我的存储库的所有接口，但我的DataAccess项目包含它们的所有具体实现。
您不希望DataContext等内容泄漏到您的域项目中。在onion architecture之后，您的域名不应该依赖外部基础架构...我会认为DataAccess具有这一点，因为它直接绑定到数据库。
将它们拆分意味着我的域不依赖于任何ORM或数据库，因此如果需要，我可以轻松地将它们交换出来。
干杯，
查尔斯
聚苯乙烯。您的项目依赖性是什么样的？我一直想知道在哪里放置我的ViewModels。也许一个单独的UI项目是一个好主意，但我不完全确定它是如何工作的。它们如何流经应用程序的不同项目层？