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

Question

我已经使用 ASP.net MVC 大约两年了，我仍在学习构建应用程序的最佳方法。

我想把我收集到的这些想法扔掉，看看它们在社区中是否是设计 MVC 应用程序的“可接受的”方式。

这是我的基本布局:

数据访问项目 - 包含所有存储库类、LINQ-to-SQL 数据上下文、过滤器和非 MS SQL 数据库存储库的自定义业务对象(LINQ-to-SQL 不会创建)。存储库通常只有它们管理的对象的基本 CRUD。

服务项目 - 包含执行业务逻辑的服务类。他们接受 Controller 的命令并告诉存储库该做什么。

UI项目 - 包含 View 模型和一些围绕诸如 ConfigurationManager(用于单元测试)之类的东西的包装器。

主MVC项目 - 包含 Controller 和 View ，以及 javascript 和 css。

这似乎是构建 ASP.NET MVC 2 应用程序的好方法吗？还有其他想法或建议吗？

View 模型是否用于 View 的所有输出和 View 的输入？

我倾向于为每个需要在 View 中显示数据的业务对象制作 View 模型，并使它们成为具有一堆属性的基本类，这些属性都是字符串。这使得处理 View 非常容易。然后服务层需要管理从 View 模型到业务对象的映射属性。这是我有些困惑的根源，因为我在 MVC/MVC2 上看到的大多数示例都没有使用 View 模型，除非您需要像组合框这样的东西。

如果您使用 MVC 2 的新模型验证，那么您是否会验证 viewmodel 对象而不必担心将验证属性放在业务对象上？

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

谢谢!

Answer 1

有趣的。

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

你不想要像 DataContext 这样的东西泄漏到您的域项目中。关注 onion architecture您的域不应该对外部基础架构有任何依赖...我会考虑 DataAccess 拥有它，因为它直接绑定(bind)到数据库。

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

干杯，
查尔斯

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