关于构建 asp.net mvc 应用程序的建议 [英] advice on architecting asp.net mvc applications
问题描述
我已经使用 ASP.net MVC 大约两年了，我仍在学习构建应用程序的最佳方法.
I've been using ASP.net MVC for about two years now and I'm still learning the best way to structure an application.
我想抛弃我收集的这些想法，看看它们是否是社区中可接受"的设计 MVC 应用程序的方式.
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.
这是我的基本布局:
DataAccess 项目 - 包含所有存储库类、LINQ-to-SQL 数据上下文、过滤器和非 MS SQL 数据库存储库的自定义业务对象(LINQ-to-SQL 没有'不创建).存储库通常只有他们管理的对象的基本 CRUD.
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 项目 - 包含视图模型和一些包装器，例如 ConfigurationManager(用于单元测试).
UI Project - Contains view models and some wrappers around things like the ConfigurationManager (for unit testing).
主 MVC 项目 - 包含控制器和视图，以及 javascript 和 css.
Main MVC Project - Contains controllers and views, along with javascript and css.
这看起来是构建 ASP.NET MVC 2 应用程序的好方法吗?还有其他想法或建议吗?
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?
我倾向于为每个需要在视图中显示数据的业务对象创建视图模型，并使用一堆全是字符串的属性使它们成为基本类.这使得处理视图变得非常容易.然后服务层需要管理从视图模型到业务对象的映射属性.这是我有些困惑的根源，因为我在 MVC/MVC2 上看到的大多数示例都不使用视图模型，除非您需要像组合框这样的东西.
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.
如果您使用 MVC 2 的新模型验证，那么您是否会验证 viewmodel 对象而不必担心将验证属性放在业务对象上?
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?
谢谢！
推荐答案
有趣.
我做的一件不同的事情是我将我的 DataAccess 项目从我的域项目中分离出来.域项目仍然包含我的存储库的所有接口，但我的 DataAccess 项目包含它们的所有具体实现.
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.
您不希望 DataContext 之类的东西泄漏到您的域项目中.遵循 洋葱架构，您的域不应依赖于外部基础设施...我会考虑 DataAccess 拥有它，因为它直接绑定到数据库.
You don't want stuff like DataContext leaking 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.
拆分它们意味着我的域不依赖于任何 ORM 或数据库，因此我可以在需要时轻松地将它们换掉.
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.
干杯，
查尔斯
附言.你的项目依赖是什么样的?我一直在想把我的 ViewModel 放在哪里.也许一个单独的 UI 项目是个好主意，但我不完全确定这将如何工作.它们如何流经您应用程序的不同项目层?
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?
这篇关于关于构建 asp.net mvc 应用程序的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
