关于构建asp.net mvc应用程序的建议

Question

我已经使用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对象而不必担心将验证属性放在业务对象上？

如何对这种类型的验证进行单元测试,或者我不应该单元测试返回的验证消息？

谢谢!

Answer 1

有趣的。

我做的一件事不同的是，我将 DataAccess 项目从 Domain 项目中分离出来。域项目仍然包含我的存储库的所有接口，但我的 DataAccess 项目包含它们的所有具体实现。

您不希望诸如DataContext泄漏到您的域项目中之类的东西。遵循洋葱架构您的域不应该对外部基础设施有任何依赖...我认为 DataAccess 具有这一点，因为它直接绑定到数据库。

将它们分开意味着我的域不依赖于任何 ORM 或数据库，因此如果需要，我可以轻松地交换它们。

干杯，
查尔斯

诗。您的项目依赖关系是什么样的？我一直想知道将我的 ViewModel 放在哪里。也许一个单独的 UI 项目是个好主意，但我不完全确定它是如何工作的。它们如何流经应用程序的不同项目层？