MVC3 应用程序/服务层/存储库层/POCO 类/EF4 - 问题！
我对整个设计概念很陌生，在过去几周的阅读中，我收集了很多信息，但似乎分散且相互矛盾。术语很复杂，我很难理解这个问题。
我使用的模式是这样的，并假设流程如下：
MVC 应用程序
控制器处理来自客户端的给定视图的请求/响应。在控制器的操作方法内，它们联系服务（服务层）并请求对象来构建视图模型，然后从视图模型发送回对象。
查看模型
我在视图之间使用强类型视图模型。
视图模型是 DTO 吗？它们应该只包含简单的属性，如名称、地址线1、地址城市等，还是应该包含复杂的属性、多个对象等。
是在视图模型中进行验证。如果是的话，是否是像必填字段、字段长度等验证。然后像用户名这样的验证已经存在，或者您需要与服务层中的其他对象进行交互？
视图模型是否可以只包含从 EF 返回的 POCO 类，或者我应该使用 AutoMapper？
如果使用 AutoMapper 和 DTO，DTO 是 POCO 类的克隆吗？
您会在控制器、视图模型还是下面的服务层中进行映射吗？
服务
对我来说，服务是联系存储库以从 EF 获取 POCO 对象的对象。这是我所有的业务逻辑所在。一旦服务将对象交回存储库以持久保存到 EF，它们就被视为有效对象。这是正确的吗？
存储库
它们中没有业务逻辑，它们只是用于在服务和 EF 之间传输对象。这是正确的吗？我在这里使用通用存储库实现接口。那么您可以扩展通用存储库以满足特殊需求吗？
有关术语的问题
1）业务对象等于领域对象吗？领域对象应该包含多少逻辑？
2）领域模型是EF模型吗？我正在使用模型优先方法。
3）依赖注入——我应该使用这个吗？我明白它是如何工作的，只是没有得到真正的好处。我正在和 Ninject 一起玩。
我认为社区将从某种包含代码示例的最佳实践的 wiki 中受益。那里有类似的东西吗？许多示例都非常简单，并且许多 Microsoft 示例即使声称使用了此模式，也没有使用此模式。
预先感谢所有曾经和将会在这方面帮助我的人。
顺便说一句 - 我认为 StackOverflow 需要在“接受答案”复选框旁边添加一个“给我买瓶啤酒”按钮:)
I am new to this whole design concept, and in reading for the last few weeks I have gathered a lot of information, but it seems scattered and conflicted. Terms are mixed, and I am just having a hard time wrapping my mind around this.
The pattern I am using is like this and assume the flow as follows:
MVC Application
The controller(s) process the request/response from the client for a given view. Inside the controllers action methods, they contact the services (Service Layer) and either request objects to build the view models, and sen the objects from the view models back.
View Models
I am using strongly typed view models to and from the views.
Are view models DTO's? Should they contain just simple properties like Name, AddressLine1, Address City, etc, or should they contain complex properties, multiple objects, etc.
Is the validation in the view model. If so would it be validation like required fields, field length, etc. Then validation like user name already exists, or where you would need to interact with other objects in the service layer?
Can the view models just contain the POCO classes returned from EF, or should I be using the AutoMapper?
If using AutoMapper and DTO, are DTO's clones of the POCO classes?
Would you map in the controller, view model, or in the service layer below?
Services
To me, the service(s) are objects that contact the repository(s) to get POCO objects back from the EF. This is where all of my business logic is. Once the service hands an object back to a repository to be persisted to the EF, they are considered valid objects. Is this correct?
Repositories
There is no business logic in them, they are just used to transport objects between the service(s) and the EF. Is this correct? I am implementing Interfaces here with generic repository. Then you could extend the generic repository for special needs?
Questions About Terminology
1) Is a business object equal to a domain object? How much logic should a domain object contain?
2) Is the domain model the EF model? I am using the Model-First approach.
3) Dependency Injection - Should I be using this? I understand how it works, just don't get the real benefit. I was playing with Ninject.
I think the community would benefit from some sort of wiki that contained all the best practices with code samples. Is there something like that out there? A lot of the samples out there are very simple, and a lot of the Microsoft samples do not use this pattern even when claiming to.
Thanks in advance to everyone who has and will help me with this.
BTW - I think StackOverflow needs a little, "Buy Me A Beer" button next to the "Accept Answer" checkbox :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
可以被认为是控制器和视图之间的一种数据传输对象。
理想情况下是简单的属性，但也可以聚合其他视图模型，但没有模型（例如：像 EF 模型）。
有两种类型的验证逻辑：进入服务层的业务验证（例如，用户名已存在）和进入视图模型的 UI 验证（例如：需要用户名）。
视图模型中没有 EF。视图模型是 POCO 类，具有简单属性和指向其他视图模型的其他复杂属性。它们还可以包含方法，以便正确格式化将在这些模型所针对的特定视图上呈现的数据。
不确定我理解这个问题。
控制器。
是的。
如果您使用 EF 代码优先方法，则可以，否则不行（如果 EF 使用 EF 特定属性和类污染域）。
是的。
是的，但不要太花哨。通常存储库用于 CRUD 操作。它是应该包含业务逻辑的服务。
是的。
这将取决于您正在处理的特定项目的域逻辑数量，以及您可以从您或其他人处理过的旧项目中重用的任何现有域逻辑。
是的，绝对是。
它在应用程序的不同层之间提供了较弱的耦合，这反过来又使它们更容易在其他项目中进行单元测试和重用。
我同意。
我对此表示怀疑。
非常同意。
Could be considered a sort of data transfer objects between the controller and the view.
Ideally simple properties but could also aggregate other view models but no models there (ex: like EF models).
There are two type of validation logic: business validation (ex. username already exists) which goes into the service layer and UI validation (ex: username is required) which goes into the view model.
No EF in view models. View models are POCO classes with simple properties and other complex properties pointing to other view models. They could also contain methods in order to properly format the data that will be presented on the particular view those models were intended for.
Not sure I understand this question.
The controller.
Yes.
If you are using EF Code first approach then yes, otherwise no (if EF pollutes the domain with EF specific attributes and classes).
Yes.
Yes, but don't get too fancy. Normally Repositories are for CRUD operations. It's services that should contain the business logic.
Yes.
This will depend on the amount of domain logic you have for the particular project you are working and on any existing domain logic you could reuse from older projects you or someone else have worked on.
Yes, absolutely.
It provides weaker coupling between the different layers of your application which in turns makes them easier to unit test and reuse in other projects.
I agree.
I doubt it.
Can't agree more.