问题标签 [service-layer]

我正在开发一个产品，该产品使用 SSIS 通过平面文件从大型机导入数据。SSIS 包使用阶段数据库来转换平面文件数据，然后调用 ODS 中的存储过程来加载转换后的数据。有一个潜在的计划是通过 .NET 服务层（而不是通过存储过程直接到 ODS）路由所有 ETL 数据，以集中业务规则/活动等。我正在寻找有关这种方法的输入和不同意见。

@ManyToOne目前我有一个与其父实体有关联的子实体。以前的开发人员已经将此字段设置为lazy="false"在会话关闭时在需要时获取父级，但是我决定它应该是lazy="true"因为它并不总是使用但是这样做时我遇到了LazyInitializationException，因为会话已关闭并且子级与尝试获取父级时的会话。

我想知道将如下所示的方法的更多逻辑移动run到与 s 交互的服务类是否正确，DAO因此我可以避免异常，因为当前服务类就像普通类一样，DAO注入了所需的 s 并且它们只是调用方法并DAO返回结果。我是否应该在与实体交互的服务类中放置更多方法，这将获取用户并检查所有登录操作，如果需要则获取父级，然后将登录结果返回给run方法..

我使用 Spring<tx:advice>来处理关闭和其他与事务相关的事情。

我最近被Jani Hartikainen在讨论如何最好地处理 MVC 应用程序中的表单数据时介绍了服务层。在做了一些阅读之后，我真的可以看到这种方法的好处。我的问题是这样的：

服务类应该如何构建？

• 首先，user_service()我的模型是合适的类名user()还是有其他标准？
• 由于我的服务中的方法只会执行一项任务，因此认为这些总是可以是正确的static function吗？服务类不代表数据，而是一系列动作，所以这似乎是合适的。
• 服务方法是否应该只接受一个argument，这将是一个array？

考虑一个表单已将数据发布到控制器以保存用户数据：

我觉得这是一个很好的方法，因为：

• 我可以在我的表单中添加另一个字段，我不必更新controller，只需更新service. 控制器不应该关心正在传递什么数据，这似乎是正确的，只要它被传递。这使我的控制器很小，并且我的模型中的逻辑。
• 如果我没有通过array，我可以设置带有多个参数的函数。例如我的功能可能是update_preferences($firstname, $lastname, $email). 然而，这可能会使函数具有超过 20 个参数（对于大型形式），并且使用顺序会变得很糟糕。
• 我可以通过一个object，但这有意义吗？如果我正在创建一个对象，它应该是它所代表的对象（在这种情况下是用户）对吗？但是控制器实例化用户对象有意义吗？这不是服务层的重点吗？
• 也许有一些方法有多个参数（当只有一到三个时）和一些接受数组的方法（当有很多字段时）。这似乎是一场噩梦，因为您总是必须引用该类才能知道该特定方法要求什么。

有人对这里的正确做法有意见吗？我在正确的轨道上吗？你过去做了什么？非常感谢！

我在一个带有遗留服务层的项目上工作，如果请求的记录不存在，或者由于调用者未经授权而无法访问，该服务层会在许多地方返回 null。我说的是 ID 要求的特定记录。例如，类似：

我最近推动了这个 API 的更改，或者补充了一个引发异常的新 API。关于已检查与未检查异常的争论随之而来。

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

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

为什么 JPA/EJB 和 Hibernate 等项目的设计者选择使用未经检查的异常模型？有很好的理由吗？有什么优点/缺点。使用这些框架的开发人员是否仍应使用适配器包装器之类的东西处理接近抛出异常的位置的运行时异常？

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

快一个。服务和服务层有什么区别？我在互联网上找不到好的答案

多年来，我一直在一遍又一遍地（随着进化）重新实现相同的代码，却没有找到某种干净、有效的方法，将其抽象出来。

该模式是我的服务层中的基本“find[Type]s”方法，它将选择查询创建抽象到服务中的单个点，但支持快速创建更易于使用的代理方法的能力（参见示例 PostServivce::getPostById () 方法方式如下）。

不幸的是，到目前为止，我一直无法满足这些目标：

1. 减少由不同的重新实现引入的错误的可能性
2. 向 IDE 公开有效/无效参数选项以进行自动完成
3. 遵循 DRY 原则

我最近的实现通常类似于以下示例。该方法采用一组条件和一组选项，并从中创建并执行一个 Doctrine_Query（我今天主要将其重写，因此可能存在一些拼写错误/语法错误，它不是直接剪切和粘贴）。

呼

这个基函数的好处是：

1. 它使我能够随着架构的发展快速支持新的条件和选项
2. 它允许我在查询中快速实现全局条件（例如，添加一个默认为 true 的 'excludeDisabled' 选项，并过滤所有 disabled = 0 模型，除非调用者明确表示不同）。
3. 它允许我快速创建新的、更易于使用的方法，这些方法代理回调 findPosts 方法。例如：

这种方法的主要缺点是：

• 在每个模型访问服务中都创建了相同的整体“find[Model]s”方法，大部分情况下只有条件切换构造和基表名称发生变化。
• 没有简单的方法来执行 AND/OR 条件操作。所有条件都明确地与。
• 引入了许多拼写错误的机会
• 在基于约定的 API 中引入了许多中断的机会（例如，以后的服务可能需要实现不同的语法约定来指定 orderBy 选项，这对于向后移植到所有以前的服务变得乏味）。
• 违反 DRY 原则。
• 有效条件和选项对 IDE 自动完成解析器隐藏，选项和条件参数需要冗长的文档块解释来跟踪允许的选项。

在过去的几天里，我试图为这个问题开发一个更面向对象的解决方案，但我觉得我正在开发一个过于复杂的解决方案，这个解决方案将过于僵化和限制使用。

我正在努力的想法类似于以下内容（当前项目将是 Doctrine2 仅供参考，所以略有改变）......

最后，Foo\Service\PostService\FindConditions 类的示例：

Foo\Options\FindConditions 和 Foo\Options\FindOptions 非常相似，因此，至少目前它们都扩展了一个通用的 Foo\Options 父类。这个父类处理初始化允许的变量和默认值，访问设置的选项，限制访问仅定义的选项，并为 DqlOptionsMapper 提供一个迭代器接口来循环选项。

不幸的是，在研究了几天之后，我对这个系统的复杂性感到沮丧。照原样，这仍然不支持条件组和 OR 条件，并且指定备用条件比较运算符的能力已经完全陷入了创建 Foo\Options\FindConditions\Comparison 类在指定 FindConditions 时环绕一个值的泥潭值 ( $conditions->setCondition('Foo', new Comparison('NOT LIKE', 'bar'));)。

如果存在的话，我宁愿使用其他人的解决方案，但我还没有遇到任何可以满足我要求的东西。

我想超越这个过程，回到实际构建我正在从事的项目，但我什至看不到结束的迹象。

所以，Stack Overflowers： - 有没有更好的方法可以提供我已经确定的好处而不包括缺点？

我想知道我的服务是我的 ArticleRepository（Doctrine 2）和我的控制器（Zend 框架）之间的一个层，是否应该负责身份验证/授权，或者它应该是另一个服务/层的一部分？

我想知道，因为我需要将我的服务用于网站的 Zf 控制器和远程客户端的 API。

反馈？

我目前正在从事的项目有一个核心 API，它被所有东西使用：服务、网络、...

该 API 有以下几层：

• 核
• 核心模型
• Core.DataProviders
• Core.DataProviders.LinqToSql
• 核心工具

在这个 API 之上是我的 ASP.NET MVC 应用程序。这看起来像这样：

• 网络
• Web.Models（一些特定于 Web 的对象和逻辑。例如，一个构建季度列表以帮助我在调度表中呈现一天的类。）
• Web.Extensions (Html Helpers, Controller base..)
• Web.ViewModels（要传递给视图的复合对象。）
• Web.Services（与 Core 和 Web.Models 通信的层。该层为我的控制器构建 ViewModels。帮助保持我的控制器清洁。）

这个设置有什么严重的缺陷吗？

一个更具体的问题：我需要先解析一些来自我的视图的东西，然后才能将它们传递给核心。我应该在 Controller 还是在 Service 层处理这个问题？

我正在学习一般的发展策略，但我对它们有很多疑问。其中之一是关于创建不应具有依赖关系的应用层表示层。例如，在 MVC 应用程序中，假设我们有应用程序服务，但此应用程序服务不检查来自表示层的传入数据模型的验证。它仅通过 ASP.NET MVC 验证在控制器中检入，而且服务层不包含任何授权内容。所有工作都在表示层完成。你认为这是正确的架构吗？我是否必须再次在服务层中包含所有验证和授权？如果你说是，但如何？

如何在服务层中包含授权？我真的不知道如何控制服务层内的授权。在服务层中复制验证也可以吗？

毕竟，如果我确定表示层永远不会改变，那么做这样的设计真的值得吗？

我试图找出构建易于维护和可测试的架构的最佳方法。在经历了几个项目之后，我看到了一些非常糟糕的架构，我想避免在我自己的项目中犯下未来的错误。

假设我正在构建一个相当复杂的三层应用程序，并且我想使用 DDD。我的问题是，我应该把我的业务逻辑放在哪里？有人说它应该放在服务（服务层）中，这确实有道理。拥有许多遵守单一职责原则的服务是有道理的。

但是也有人说这是一种反模式，业务逻辑不应该在服务层实现。为什么是这样？

假设我们有IAuthenticationService一个带有bool UsernameAvailable(string username)签名的方法。该方法将实现所有必需的逻辑来检查用户名是否可用。

根据“这是反模式”的人群，这里有什么问题？