关于构建 ASP.NET MVC 应用程序的建议
我已经使用 ASP.net MVC 大约两年了，而且我仍在学习构建应用程序的最佳方法。
我想扔掉我收集到的这些想法，看看它们是否是社区中“可接受”的设计 MVC 应用程序的方式。
这是我的基本布局：
DataAccess 项目 - 包含所有存储库类、LINQ-to-SQL 数据上下文、过滤器和非 MS SQL 数据库存储库（即 LINQ-to-SQL）的自定义业务对象-SQL 不创建）。存储库通常只对它们所管理的对象提供基本的 CRUD。
服务项目 - 包含执行业务逻辑的服务类。它们接受控制器的命令并告诉存储库要做什么。
UI 项目 - 包含视图模型和一些围绕 ConfigurationManager 等内容的包装器（用于单元测试）。
主 MVC 项目 - 包含控制器和视图，以及 javascript 和 css。
这看起来是构建 ASP.NET MVC 2 应用程序的好方法吗？还有其他想法或建议吗？
视图模型是否用于所有视图的输出和视图的输入？
我正在尝试为每个需要在视图中显示数据的业务对象创建视图模型，并使其成为具有一堆全是字符串的属性的基本类。这使得处理视图变得非常容易。然后，服务层需要管理从视图模型到业务对象的映射属性。这是我感到困惑的一个根源，因为我在 MVC/MVC2 上看到的大多数示例都不使用视图模型，除非您需要诸如组合框之类的东西。
如果您使用 MVC 2 的新模型验证，您是否会验证视图模型对象，而不必担心将验证属性放在业务对象上？
如何对这种类型的验证进行单元测试，或者我不应该对返回的验证消息进行单元测试吗？
谢谢！
I've been using ASP.net MVC for about two years now and I'm still learning the best way to structure an application.
I wanted to throw out these ideas that I've gathered and see if they are "acceptable" ways in the community to design MVC applications.
Here is my basic layout:
DataAccess Project - Contains all repository classes, LINQ-to-SQL data contexts, Filters, and custom business objects for non-MS SQL db repositories (that LINQ-to-SQL doesn't create). The repositories typically only have basic CRUD for the object they're managing.
Service Project - Contains service classes that perform business logic. They take orders from the Controllers and tell the repositories what to do.
UI Project - Contains view models and some wrappers around things like the ConfigurationManager (for unit testing).
Main MVC Project - Contains controllers and views, along with javascript and css.
Does this seem like a good way to structure ASP.NET MVC 2 applications? Any other ideas or suggestions?
Are view models used for all output to views and input from views?
I'm leaning down the path of making view models for each business object that needs to display data in the view and making them basic classes with a bunch of properties that are all strings. This makes dealing with the views pretty easy. The service layer then needs to manage mapping properties from the view model to the business object. This is a source of some of my confusion because most of the examples I've seen on MVC/MVC2 do not use a view model unless you need something like a combo box.
If you use MVC 2's new model validation, would you then validate the viewmodel object and not have to worry about putting the validation attributes on the business objects?
How do you unit test this type of validation or should I not unit test that validation messages are returned?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有趣的。
我做的一件事不同的是，我将 DataAccess 项目从 Domain 项目中分离出来。域项目仍然包含我的存储库的所有接口，但我的 DataAccess 项目包含它们的所有具体实现。
您不希望像
DataContext这样的东西泄漏到您的域项目中。遵循洋葱架构，您的域不应有任何依赖外部基础设施...我认为 DataAccess 具有该功能，因为它直接与数据库绑定。将它们分开意味着我的域不依赖于任何 ORM 或数据库，因此如果需要，我可以轻松地交换它们。
干杯，
查尔斯·
诗篇。您的项目依赖关系是什么样的？我一直想知道将我的 ViewModel 放在哪里。也许一个单独的 UI 项目是个好主意，但我不完全确定它是如何工作的。它们如何流经应用程序的不同项目层？
Interesting.
One thing I do differently is that I split off my DataAccess project from my Domain project. The domain project still contains all the interfaces for my repositories but my DataAccess project contains all the concrete implementations of them.
You don't want stuff like
DataContextleaking into your domain project. Following the onion architecture your domain shouldn't have any dependencies on external infrastructure... I would consider DataAccess to have that because it's directly tied to a database.Splitting them off means that my domain doesn't have a dependency on any ORM or database, so I can swap them out easily if need be.
Cheers,
Charles
Ps. What does your project dependency look like? I've been wondering where to put my ViewModels. Maybe a separate UI project is a good idea, but I'm not entirely sure how that would work. How do they flow through the different project tiers of your application?