MVC3应用程序/服务层/库层/ POCO类/ EF4 - 问题！ [英] MVC3 App/Service Layer/Repository Layer/POCO Classes/EF4 - Questions!

问题描述

我是新来这个整体的设计理念，并在阅读过去几周我已经收集了很多资料，但似乎散冲突。术语是混合，我只是有一个很难包装我的脑海里解决这个问题。

我使用的模式是这样的，承担的流程如下：

MVC应用程序结果
控制器（多个）处理给定视图中的请求/从客户端的响应。内部控制器动作方法，他们联系服务（服务层），要么请求对象从视图模型构建视图模型，并仙的对象了。

视图模型结果
我使用强类型的视图模型，并从意见。

是视图模型DTO的？他们应该只包含简单的属性，如名称，AddressLine1，地址城市等，还是应该包含复杂属性，多个对象，等等。

时的视图模型的验证。如果是的话会是像必填字段，字段长度等，然后验证，如用户名已经存在，或者你需要在服务层与其他对象进行交互？

验证

视图模型可以只包含从EF返回的POCO类，或者我应该使用AutoMapper？

如果使用AutoMapper和DTO，是POCO类的DTO的克隆？

你会在控制器地图，浏览模式，或在下面的服务层？

服务结果
对我来说，服务（S）是联系版本库（S），以获得POCO对象从EF后面的对象。这是我所有的业务逻辑是。一旦服务手里的对象返回到存储库被持久化到EF，他们被认为是有效的对象。这是正确的？

库结果
有一个在他们没有业务逻辑，它们只是用来服务（S）和EF之间传输的对象。它是否正确？我在这里实现接口与普通的存储库。然后，你可以为特殊需要扩展一般的资料库？

问题有关术语结果
1）是一个业务对象等于域对象？域对象应该是多少逻辑包含哪些内容？

2）是域模型中的EF模型？我现在用的模型第一种方法。

3）依赖注入 - 我应该使用吗？我理解它是如何工作的，只是没有得到真正的好处。我玩Ninject。

我认为社会会从某种维基包含所有code样品的最佳实践中受益。是否有类似的东西在那里？很多样品在那里都非常简单，和很多微软的样本自称时候甚至不使用这种模式。

在此先感谢大家谁已经并将帮助我。

顺便说一句 - 我认为计算器需要一点点，我买啤酒按钮旁边的接受答案复选框：）

解决方案

  

是视图模型DTO的？

可以被视为一种控制器和视图之间的数据传输对象。

  

他们应该只包含简单的属性，如名称，AddressLine1，地址城市等，还是应该包含复杂属性，多个对象，等等。

在理想情况下简单的属性但也聚集其他视图模型，但没有模型存在。（例如：喜欢EF型号）

  

时的视图模型的验证。

有两种类型的验证逻辑：业务验证其进入服务层和用户界面验证（如用户名已经存在）。（例如：需要用户名），它进入视图模型

  

视图模型可以只包含从EF返回的POCO类，或者我应该使用AutoMapper？

在视图模型没有EF。查看模型是POCO类简单的物业及其他复杂属性指向其他视图模型。它们也可以包含以正确地格式化，这将是psented这些模型被用于所述特定视图$ P $的数据的方法。

  

如果使用AutoMapper和DTO，是POCO类的DTO的克隆？

不知道我理解这个问题。

  

你会在控制器地图，浏览模式，或在下面的服务层？

控制器。

  

对于我来说，服务（S）是联系版本库（S），以获得POCO对象从EF后面的对象。这是我所有的业务逻辑是。一旦服务手里的对象返回到存储库被持久化到EF，他们被认为是有效的对象。这是正确的？

是

  

时域模型的EF模式？

如果您使用的是EF code第一种方法然后是，否则没有（如果EF污染与EF特定的属性和类域）。

  

有是在其中没有业务逻辑，它们只是用来服务（S）和EF之间传输的对象。它是否正确？

是

  

我在这里实现接口与普通的存储库。然后，你可以为特殊需要扩展一般的资料库？

是的，但不要太花哨。通常库都是CRUD操作。它提供的服务应该包含业务逻辑。

  

是一个业务对象等于域对象？

是的。

  

多少逻辑应该域对象包含哪些内容？

这将取决于你有你的工作和任何现有域逻辑，你可以从你或其他人工作过的旧项目重复使用特定项目领域逻辑的数量。

  

依赖注入 - ？我应该使用这种

是的，绝对。

  

我理解它是如何工作的，只是没有得到真正的好处

它提供了应用程序的不同层这反过来使他们更容易在其他项目的单元测试和重用之间弱耦合。

  

我认为社会会从某种维基包含与code样品所有的最佳实践中受益。

我同意。

  

有没有类似的东西在那里？

我对此表示怀疑。

  

顺便说一句 - 我认为计算器需要一点点，我买啤酒按钮旁边的接受答案复选框。

不能同意。

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 :)

解决方案

Are view models DTO's?

Could be considered a sort of data transfer objects between the controller and the view.

Should they contain just simple properties like Name, AddressLine1, Address City, etc, or should they contain complex properties, multiple objects, etc.

Ideally simple properties but could also aggregate other view models but no models there (ex: like EF models).

Is the validation in the view model.

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.

Can the view models just contain the POCO classes returned from EF, or should I be using the AutoMapper?

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.

If using AutoMapper and DTO, are DTO's clones of the POCO classes?

Not sure I understand this question.

Would you map in the controller, view model, or in the service layer below?

The controller.

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?

Yes.

Is the domain model the EF model?

If you are using EF Code first approach then yes, otherwise no (if EF pollutes the domain with EF specific attributes and classes).

There is no business logic in them, they are just used to transport objects between the service(s) and the EF. Is this correct?

Yes.

I am implementing Interfaces here with generic repository. Then you could extend the generic repository for special needs?

Yes, but don't get too fancy. Normally Repositories are for CRUD operations. It's services that should contain the business logic.

Is a business object equal to a domain object?

Yes.

How much logic should a domain object contain?

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.

Dependency Injection - Should I be using this?

Yes, absolutely.

I understand how it works, just don't get the real benefit

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 think the community would benefit from some sort of wiki that contained all the best practices with code samples.

I agree.

Is there something like that out there?

I doubt it.

BTW - I think StackOverflow needs a little, "Buy Me A Beer" button next to the "Accept Answer" checkbox

Can't agree more.

这篇关于MVC3应用程序/服务层/库层/ POCO类/ EF4 - 问题！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！