标签: service-layer

为了理解MVC 2并试图让我的公司将其作为未来发展的可行平台,我最近一直在做很多阅读.在过去的几年里,我一直专注于ASP.NET,我有一些赶上来做.

目前,我了解存储库模式,模型,控制器,数据注释等.但是有一件事让我无法完全理解,无法开始参考应用程序的工作.

第一个是服务层模式.我在Stack Overflow上阅读了很多博客文章和问题,但我仍然不完全理解这种模式的目的.我在MVCCentral上观看了高尔夫跟踪应用程序中的整个视频系列,并查看了他发布的演示代码,它看起来像服务层只是存储库模式的另一个包装器,根本不执行任何工作.

我也读过这篇文章:http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx,但它似乎有点回答了我的问题,但是,如果你使用数据注释来执行验证,这个似乎没必要.

我已经寻找过演示,帖子等等,但我似乎找不到任何简单解释模式的东西,并给我提供了令人信服的证据来使用它.

有人可以请我提供二年级(好的,可能是五年级)使用这种模式的理由,如果我不这样做会失去什么,如果我这样做会得到什么？

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

但要使其工作,存储库必须返回该DTO的实例.否则,您首先必须将存储库返回的数据层对象映射到服务层中的DTO并返回该对象.这看起来很浪费.

最重要的是,如果DTO的创建发生在服务层中,那么在一个存储库调用之前可能已经完成的事情以及因此一个数据库查询现在必须在服务层中的多个存储库调用发生以"组合"最终的DTO.当然,除非我在数据和服务层之间创建一个可以包含这样一个组合对象的传输对象.这则必须映射到DTO.为了纯洁,这似乎是浪费.但是,让存储库层返回仅通过线路发送的对象也是错误的.

我是这个整体设计概念的新手,在过去几周的阅读中,我收集了大量的信息,但它似乎分散且矛盾.条款喜忧参半,我只是很难想到这一点.

我使用的模式是这样的,并假设流程如下:

MVC应用程序
控制器处理来自客户端的给定视图的请求/响应.在控制器操作方法内部,它们联系服务(服务层)并请求对象以构建视图模型,并从视图模型中检索对象.

视图模型
我在视图中使用强类型视图模型.

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

是视图模型中的验证.如果是这样,它将是必需的字段,字段长度等验证.然后验证用户名已经存在,或者您需要与服务层中的其他对象进行交互？

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

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

您会在控制器,视图模型或下面的服务层中进行映射吗？

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

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

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

2)域模型是EF模型吗？我正在使用Model-First方法.

3)依赖注入 - 我应该使用它吗？我理解它是如何工作的,只是没有得到真正的好处.我和Ninject一起玩.

我认为社区将受益于某种包含代码示例的所有最佳实践的wiki.那里有类似的东西吗？很多样本都非常简单,很多微软样本即使在声称时也不使用这种模式.

提前感谢所有拥有并将帮助我的人.

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

我正在创建一个MVC网站,并打算创建一个Web API,以便在网站内使用,也可能由第三方使用.

从MVC控制器,我将调用一个服务层,它将包含业务逻辑,作用于域模型,执行验证,进行基础设施外部服务调用等.服务层反过来将调用存储库以进行任何数据库交互.

现在,我喜欢ServiceStack的外观,并打算将它用于Web API - 它似乎比ASP.NET MVC 4 Web API更成熟.我的问题是,我应该在上面的服务层中调用ServiceStack API,类似于MVC控制器,还是应该将其作为服务层,为Web客户端和MVC控制器提供服务？

我不确定我在JSF中使用MVC环境的方法是否是最好的方法.由于我想要充分利用JSF,我想知道我的服务层(或模型,用MVC术语说)应该如何"设计".

我知道视图 - 控制器比率应该是1比1(排除例外情况).现在我应该以什么方式设计我的服务层？我应该使用一项大型服务(不这么认为)吗？如果没有,根据我应该分割我的服务？

注意,我的服务将从Beans(控制器以MVC术语)调用,服务本身将在必要时使用JPA调用DAO.

提前致谢

题

在MVC Web应用程序中跨多个存储库共享EF DbContext的正确方法是什么？这样做是否谨慎/必要,做或不做的陷阱是什么？

背景

假设:

• App.MvcSite(几十个控制器,多个区域等)
• App.Services(服务层,许多服务)
• App.Data(许多存储库等)
• ......等为简单而排除(EF Code First latest)

研究迄今

我似乎在SO和互联网上找到了至少两三个思想流派.

1. 将DbContext共享/范围扩展到请求,以便单个请求具有所有存储库共享的单个DbContext.
2. 在服务层共享/范围您的DbContext - 该服务维护单个DbContext并根据需要将其传递给每个存储库.
3. 不要共享DbContext,因为它们很便宜,让每个Repo都有自己的.

在一个小型网站中,这是一个非问题,这就是为什么大多数MS和社区的例子根本不解决这个问题.

根据我迄今为止的经验,我没有使用有限的存储库.我一直有服务使用DbContext并直接更改它所以我不需要担心这一点.我被告知,从单元测试的角度来看,有限的存储库有很大的好处......我们将看看它是否值得其余部分.

我的想法

(1)将DbContext共享/范围分配给请求

这很有意思,因为它巧妙地避免了单例上下文的陷阱,一些开发人员认为这是一个答案,但发现DbContext不能以这种方式工作.但它似乎有一个缺点,它假设所有存储库,服务等将在整个请求中协调......通常情况并非如此,对吧？如果一个仓库在另一个仓库完成其工作之前保存了更改,该怎么办 (外(内(内)))

(2)在服务层共享/调整您的DbContext

这对我来说更有意义,因为每个服务应该协调一个特定的工作单元(小写有意).因此,如果在一个请求中使用了多个服务,那么每个服务都有自己的数据库上下文是正确的(如果不是必需的话).

(3)不要共享DbContext,因为它们很便宜

这是我一直这样做的方式......实际上我几乎总是每个请求只有一个DbContext,因为只有一个服务被调用.有时它可能是两个,因为两个服务是由协调工作的控制器调用的.但鉴于我目前的应用程序,有许多有限的存储库,每个存储库都有自己的上下文,这意味着给定的请求可能有3-10个DbContext实例.我认为(可能不正确)这是有问题的.

重复问题:

在MVC Web应用程序中跨多个存储库共享EF DbContext的正确方法是什么？这样做是否谨慎/必要,做或不做的陷阱是什么？

例如,我有一个用户表,要进行分层,我创建了这样的POJO:

UserEntity.java
UserDao.java
UserBO.java(业务对象,域模型？)
UserService.java(用于服务层)

UserBO.java和UserService.java之间有什么区别？为什么我们把它分成两个对象？

我是否认为服务层的目的包括以下内容？

• 稀疏域模型(即某些函数的移动,如缓存,实例化)
• 减少域模型的依赖性
• API最小化

我处理具有遗留服务层的项目,如果请求的记录不存在,则在许多地方返回null,或者由于呼叫者未被授权而无法访问.我在谈论ID要求的特定记录.例如,类似于:

UserService.get(userId);

我最近推动改变这个API,或者补充一个抛出异常的新API.关于已检查与未经检查的例外的争论随之而来.

从JPA/Hibernate等人的设计者那里得到一个说明,我建议未经检查的异常可能是最合适的.我的论点是,无法合理地期望API的用户从这些异常中恢复,并且在99%的情况下,我们最多只能通知应用程序用户发生了一些错误.

将运行时异常传播到通用处理机制显然会减少处理边缘情况异常所涉及的许多复杂性和所需的分支处理.但是,围绕这种方法存在很多担忧(这是正确的).

为什么选择JPA/EJB和Hibernate等项目的设计者使用未经检查的异常模型？它有充分的理由吗？有什么利弊.使用这些框架的开发人员是否仍然可以使用适配器包装器之类的东西处理接近它们抛出位置的运行时异常？

我希望这些问题的答案可以帮助我们对自己的服务层做出"正确"的决定.

我正在为具有存储库层和服务层的.NET MVC应用程序确定一个相当简单的分层体系结构.我找到了一些相当清晰和简单的例子,特别是www.asp.net,以及这里的一些问题和答案,但我正在寻找一些更简单的东西,适合小型应用程序,但是它使用不同的项目,以获得跨越的想法.我上面链接的示例将存储库和服务作为Models命名空间中的类.这对我来说是不够明确的分离能够恰当地说明它.

我有一个单独的项目用于实现接口IRepository的存储库.Service有一个单独的项目,它实现了IService并获取了一个IRepository(构造函数注入).该服务实现了IService.这个例子就足以让控制器实例化服务,而不需要IoC容器.将其视为理解最佳架构实践的中间步骤,这是逐步构建包含依赖注入和可能更多层的序列的一部分.

问题是,我应该在哪里定义IRepository和IService？当然,服务和存储库项目都需要引用它们.很明显,它们应该在服务和存储库项目引用的另一个项目中定义.如果是这样,那么一个好的命名约定是什么？XXXXContracts之类的东西？

同样,对于在表示层,服务层和存储库层之间传递的数据模型,是否可以使用所有层引用的名为XXXXModels的单独项目？我知道在某些情况下,服务和存储库层之间传递的模型可能与服务层和表示层之间传递的模型不同,但原理是相同的.

我在这里找到了类似问题的答案,但它们往往涉及比我在此概述的更复杂的架构.我希望实现一个非常简单和干净的两层图解,可以看作是参考数据层并在控制器中具有业务逻辑的一两步,这就是全部.我知道有一个强有力的论据可以直接进入全面的最佳实践,但不是每个人都适合一次性完成跳跃.