问题标签 [service-layer]

假设我有用于用户注册的 RegisterModel 和一些实现 IUserService 的 UserService

鉴于 RegisterModel 可能非常复杂，将 RegisterModel 映射到 User 对象的逻辑应该在哪里

我正在使用 Entity Framework 4 创建一个 ASP.NET MVC 3 应用程序。我正在使用存储库/服务模式并正在寻找反馈。

我目前有以下内容：

MVC 应用程序 (GTG.dll)

• GTG
• GTG.控制器
• GTG.ViewModels

商业 POCO (GTG.Business.dll)

• 这包含所有业务对象（客户、订单、发票等...）

EF 模型/存储库 (GTG.Data.dll)

• GTG.Business (GTG.Context.tt) 我使用了实体 POCO 生成器模板。
• GTG.Data.Repositories

服务层 (GTG.Data.Services.dll)

• GTG.Data.Services - 包含所有服务对象，每个聚合根一个。

以下是一个小示例代码：

控制器

模型

服务

存储库

我有一个负责我的数据访问的存储库层，它由服务层调用。服务层返回被序列化并通过线路发送的 DTO。通常，服务只是访问存储库并返回存储库返回的任何内容。

但要使其正常工作，存储库必须返回该 DTO 的实例。否则，您首先必须将存储库返回的数据层对象映射到服务层中的 DTO 并返回。这似乎很浪费。

最重要的是，如果 DTO 的创建发生在服务层中，以前可能在一个存储库调用和一个数据库查询中完成的事情，现在必须通过服务层中的多个存储库调用来“组合”最终 DTO。当然，除非我在数据和服务层之间创建一个可以包含这样一个组合对象的传输对象。然后必须将其映射到 DTO 。为了纯洁，这似乎是浪费。但是让存储库层返回刚刚存在的对象以通过网络发送也感觉不对。

我已经看到很多书籍和文章示例都说要将验证代码放在您的服务层中。保持域对象“哑”（又名纯 POCO）并处理域对象可能在服务层中执行的所有验证。

服务层似乎（或至少可以）负责这么多；用户身份验证、角色身份验证、为 IoC 编写脚本依赖对象（记录器、错误处理程序等）、编写域对象脚本、编写存储库脚本以及将域对象传入和传出存储库……哇！

在服务层中创建所有这些规则不会对您的域对象构成重大威胁吗？例如，如果某些程序员决定直接针对您的域对象编写消费代码并完全绕过服务层，会发生什么情况？这将是糟糕的，但一个可信的情况。

如果您打算将很多职责放在服务层中，包括所有域对象验证，是否有办法“保护”您的域对象，是否有人试图直接编写脚本？例如，也许你的域对象现在没有被某个客户端使用（在这种情况下是服务层？）。

好的设计让我认为域对象不应该知道谁在调用它们以及如何调用它们。

如果没有办法“锁定”域对象，那么为什么有这么多文章、书籍等建议将域对象验证放在服务层中呢？我想通过采取防御性编程立场，您应该构建您的域对象以防弹，并依靠您的服务层来提供一个简单的代码层来在 UI 和 BAL/DAL 之间转发和接收请求。

有没有人从绕过他们的服务层的人那里“滥用”他们的域对象的一些实际项目经验？

我一直在开发一个新的 ASP.NET MVC 应用程序，并尽我所能使用 EF4 和 POCO 类来实现服务层/存储库/UOW 模式。

帮我看看我是否理解正确。

为了简单起见，假设客户正在请求查看客户的视图。

1) 客户端从CustomerController请求视图。
2) CustomerController创建一个新的UOW和一个传入UOW的新CustomerService。 3) CustomerService创建一个新的Repository(Of Customer)并传入它从CustomerService收到的UOW。在这一层，您可能会说“您可以查看此客户吗？”之类的内容。 4) CustomerRepository处理从EF4获取POCO类。 5)客户存储库


将POCO类交还给CustomerService，然后由 CustomerService 将它们交还给CustomerController。
6) CustomerController使用POCO类来填充CustomerViewModel，然后将CustomerViewModel交给CustomerView。

我仍然对为什么/在哪里使用 AutoMapper 有点困惑？？？

对此的任何建议将不胜感激。

我对整个设计概念很陌生，在过去几周的阅读中，我收集了很多信息，但似乎分散和矛盾。术语好坏参半，我只是很难理解这一点。

我使用的模式是这样的，假设流程如下：

MVC 应用程序
控制器处理来自客户端对给定视图的请求/响应。在控制器操作方法中，它们联系服务（服务层）并请求对象来构建视图模型，然后将视图模型中的对象发送回来。

视图模型
我在视图之间使用强类型视图模型。

视图模型是 DTO 吗？它们应该只包含简单的属性，如 Name、AddressLine1、Address City 等，还是应该包含复杂的属性、多个对象等。

是视图模型中的验证。如果是这样，它是否会像必填字段、字段长度等那样进行验证。然后像用户名这样的验证已经存在，或者您需要在服务层中与其他对象交互的地方？

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

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

你会映射到控制器、视图模型还是下面的服务层？

服务
对我来说，服务是联系存储库以从 EF 取回 POCO 对象的对象。这是我所有的业务逻辑所在。一旦服务将对象交回存储库以持久保存到 EF，它们就被视为有效对象。它是否正确？

存储库
其中没有业务逻辑，它们仅用于在服务和 EF 之间传输对象。它是否正确？我在这里用通用存储库实现接口。那么您可以扩展通用存储库以满足特殊需求吗？

关于术语
的问题 1) 业务对象是否等于域对象？域对象应该包含多少逻辑？

2）领域模型是EF模型吗？我正在使用模型优先的方法。

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

我认为社区会从某种 wiki 中受益，该 wiki 包含所有带有代码示例的最佳实践。那里有类似的东西吗？那里的许多示例都非常简单，并且许多 Microsoft 示例即使声称使用这种模式也不使用此模式。

在此先感谢所有拥有并将帮助我的人。

顺便说一句 - 我认为 StackOverflow 需要一个“接受答案”复选框旁边的“给我买啤酒”按钮 :)

我正在使用带有 EF4 的服务层/存储库/工作单元模式构建一个 MVC 应用程序。

我对逻辑有点困惑。我知道重点是解耦系统，但我有点困惑。

所以 MVC 控制器调用服务来填充视图模型。那么说 MVC 应用程序与服务层耦合是否安全？

然后服务层调用存储库来获取和持久化对象。那么可以安全地说服务层依赖于存储库吗？

存储库利用 EF4 获取数据并将数据保存到 SQL Server，因此我假设存储库依赖于 EF4，而 EF4 又依赖于 SQL Server。

工作单元在哪里都适合。

请问有什么例子吗？谢谢！！

我在我的 MVC 应用程序中使用 UnitOfWork/Service Layer/Repository/EF4 w/POCO 设计。

到目前为止，我有这个：

1) MVC Web App (Project.dll)
2) 服务层 (Project.Data.Services.dll)
3) 存储层 (Project.Data.Repositories.dll)
4) POCOS (Project.Data.Domain.dll)
5) EF4/上下文层 (Project.Data.dll)

每个图层仅引用下面的图层和 Project.Data.Domain（POCO 类）。

我目前在 Project.Data.dll 中有 UnitOfWork 接口/基础，但现在所有层都必须引用它。这是一个糟糕的设计吗？如果是这样，它住在哪里？

我仍然很难解决这个问题。我想像这样分离我的层（dll）：

1) MyProject.Web.dll - MVC Web 应用程序（控制器、模型（编辑/视图）、视图）
2) MyProject.Services.dll - 服务层（业务逻辑）
3) MyProject.Repositories.dll - 存储库
4) MyProject。 Domain.dll - POCO 类
5) MyProject.Data.dll - EF4

工作流程：

1) 控制器调用服务来获取对象以填充视图/编辑模型。
2) 服务调用存储库来获取/持久化对象。
3) 存储库调用 EF 以从 SQL Server 获取/保留对象。

我的存储库返回 IQueryable(Of T)，并在其中使用 ObjectSet(Of T)。

所以正如我所看到的，这些层完全取决于下一层和包含 POCO 类的库？

几个问题：

1) 现在我的存储库可以与 EF 一起正常工作，它们将依赖于 System.Data.Objects，现在我的存储库层与 EF 紧密耦合，这很糟糕吗？

2）我正在使用 UnitOfWork 模式。那应该住在哪里？它有一个作为 ObjectContext 的属性上下文，因此它也与 EF 紧密耦合。坏的？

3) 我如何使用 DI 使这更容易？

我希望这是一个尽可能松耦合的测试。有什么建议么？

- - - - - 编辑 - - - - -

如果我在正确的轨道上，请告诉我。此外，因此服务被注入了一个 IRepository(Of Category) 对，它如何知道它与 EFRepository(Of T) 的具体类之间的区别？与 UnitOfWork 和服务相同吗？

一旦有人帮我弄清楚我理解的地方，我知道这似乎是微不足道的，但是伙计，我有一段时间在这个问题上纠结！！

控制器

服务

存储库和工作单元

我在 MVC 应用程序中使用服务/存储库/EF/POCO 模式，并且有几个关于接口的问题。

1）我应该为每个服务创建一个接口吗？2）我应该为每个存储库创建一个接口吗？

或者，我是否应该每层都有一个通用接口（IService(Of T)、IRepository(Of T)）。

我不明白的是在控制器中怎么说，它的构造函数中需要一个 IService(Of Category) 接口，我如何在具体类中实现这些方法？

_Service 没有我的具体 CategoryService 类的方法？

有意义吗？