问题标签 [service-layer]

我正在使用标准 mvc 范例编写一个 zend 框架应用程序，并添加了一个服务层来处理应用程序/业务逻辑。将访问控制放入服务中似乎很流行，而不是模块/控制器/操作，但是，我只看到了具有静态角色和这些角色权限的简单示例。

我的应用程序将使用动态 acl，允许管理员用户添加角色并设置这些角色的权限。我有两个问题：

1. 您如何将用户空间中的权限映射到服务中的服务和方法的权限？我不认为它应该是 1:1 映射。如果您的应用程序足够大，您将拥有许多具有许多方法的服务，并且权限结构很快就会让最终用户为角色设置权限而感到困惑。
2. 我的服务对应用程序来说是全局的，而不是特定于模块的。您将如何根据访问的模块为这些服务设置权限？

任何帮助将不胜感激。

参加与其他几个班级有关系的班级。第一类可以看作是聚合（根）。从服务层的角度来看，如何最好地拆分调用？

1. 调用整个对象图的聚合存储库，并从该特定存储库调用其他存储库来处理关系的保存（每种类型的类一个存储库。
2. 调用整个对象图的聚合存储库并在一个方法中处理所有内容（因此将所有关系保存在同一方法中）。
3. 在服务层中，调用聚合的存储库，然后直接从服务层调用相关类的存储库。
4. 在服务和存储库之间添加一个额外的层，并在该额外层中执行选项 3 中的操作。

我已经在生产代码中看到了所有 3 种可能的解决方案，但我对最干净的解决方案以及选择这种方法的原因很感兴趣。

尝试在这里创建一个非常简单的存储库和服务层模式。（.NET 4、C#、LINQ，尽管这个问题部分与语言无关）。注意：这只是研发。

我的目标是最小化我的服务层中方法定义的数量。

这是我的存储库合同：

那里没有什么新鲜事。

现在，这是我（尝试）在我的服务合同中拥有的内容：

本质上，任何特定的“Foo”都有许多属性（id、name 等），我希望能够对其进行搜索。

所以，我不想为每个不同的属性使用 1x Find 方法，我只想要一个 - 这样当我创建额外的属性时，我不必修改合同。

“FooSearchArgs”只是一个简单的 POCO，它具有所有不同的“Foo”属性。

所以，这就是我想要做的，这是我的问题：

• 这是糟糕的设计吗？如果是这样，有哪些替代方案？
• 我如何在服务层实现这种过滤？我是否必须检查设置了“FooSearchArgs”的哪些属性，然后继续过滤？（如果是这样，那么 query.where，如果是这样，query.where 等） 任何人都知道一个聪明的 LINQ IEnumerable 扩展方法来做到这一点？（即repository.WhereMeetsSearchCriteria(fooSearchArgs)）

感谢帮助。

在定义我们的应用程序架构（包含 Web UI 和外部 Web 服务）时，我们偶然发现我们无法为最顶层找到一个通用名称。很明显，我们的应用程序中有 DAL（数据访问层）和 BLL（业务逻辑层）。在 BLL 的顶部，有 UI，通常称为表示层（例如， http: //msdn.microsoft.com/en-us/library/ff647339.aspx）。但是还有一个服务层，它也位于 BLL 的顶部！

但是蛋糕不能在同一层上有两层 :) 所以请帮我找到一个术语。

我查看了http://solitarygeek.com/java/developing-a-simple-java-application-with-spring/comment-page-1#comment-1639上的示例

我试图弄清楚为什么在他提供的示例中首先需要服务层。如果你把它拿出来，那么在你的客户中，你可以这样做：

看起来服务层只是 DAO 的一个包装器。有人可以给我一个案例，如果服务层被删除，事情可能会变得一团糟？我只是不明白从服务层开始的意义。

我应该在我的服务层还是在我的控制器中进行自动映射？

我喜欢存储库的想法 - 原始数据 IQueryable 类型的东西，具有完整的域（类型）对象。服务层 - 分页、有序、过滤、自动映射视图模型以返回控制器 - 使用正确的模型推送视图

但是看到一些带有 ActionFilters 和属性的好东西后，我想知道是否有更好的方法

存储库 - 具有完整域（类型）对象的原始数据 IQueryable 类型的东西。服务层 - 过滤的分页数据 域对象控制器 - 自动映射服务层数据并推送视图。

对此的任何想法将不胜感激

人们如何设计他们的服务层接口？

我正在编写一个大型 Web 应用程序（在 PHP 中），我们正在使用 MVC，并编写瘦控制器，例如（伪代码如下）

服务中的 savePerson 是否应该接受整个 $input 结构或上下文的参数（在 PHP 中，一个关联数组）？

例如这个 -

或者应该将所有输入字段分开并提供“硬”界面，例如

谢谢。

保罗

我知道这听起来可能很愚蠢，但我发现很难理解服务层的需求及其与业务层的区别。

因此，我们使用 asp.net mvc 2 并拥有数据访问层，它对数据库进行所有查询，然后我们拥有业务层，它具有需要完成的业务逻辑和验证。最后，我们有了基本上拥有所有视图的表示层。此外，作为我们库的一部分，我们还在不同的文件夹中提供了一些帮助程序、DTO 和视图模型类。但是我尝试阅读有关架构的内容，并且似乎服务层是架构的重要组成部分。

我所理解的是，服务层是调用所有功能的东西。但是我真的看不到我们的应用程序需要服务层吗？或者它可能已经存在并且我看不到它......任何人都可以用一个例子来解释服务层的重要性吗？它与业务层有何不同，因为从我所读到的内容看起来非常相似？如果它是第一个需要的？我们要做的就是以最好的方式构建我们的应用程序，您对此有何想法和经验？

我的问题是：您的服务层是否与您使用的技术绑定？

例如，如果您使用休眠，则将一些仅作为休眠功能的 hql 查询或条件查询放入服务层，或者您只需调用 DAO（并且 dao 具有休眠实现，可能还有 jdbc 实现等）？

我在为我的软件构建有效的分层架构时遇到了一些麻烦。

编辑 这是一项简单的服务……我认为这是一项服务……不受我使用的技术的约束（休眠）

这是一个使用 Dao 实现的服务

这两种方法哪一种是正确的？

编辑2

所以，总结一下我的理解：

抱歉这堵文字墙，也许对我希望的其他人有用，我朝着正确的方向前进？我的服务层需要接口吗？都是正确分层的吗？我也需要控制层吗？

谢谢。

我在想我是否真的需要一个服务层。

我正在将 spring + hibernate 用于桌面摇摆应用程序，此时我有 gui/swing 层->服务层->dao 层。我仅将 spring 用于@Transactional 支持和 IOC 注入

最佳实践说我必须编写一个服务来使用我的 daos，并将所有事务管理放在服务中。

但是我经常意识到，服务层只复制 dao 方法，例如：

这是服务层的典型用法...... Hibernate 与 db 无关，spring 与技术无关：所以，我真的需要它吗？

管理所有 DAO 的独特服务类怎么样？我认为这可能是一个很好的妥协，或者，是一个不好的做法？

我知道将@Transactional 放在DAO 上是一种不好的方法，但是此时我必须编写服务仅用于将@Transactional 放在上面...

编辑

有关我的应用程序的更多信息。

我的应用程序是一个管理软件，管理用户注册、产品、订单和其他类似的东西。在实践中，它包含许多读取实体->编辑->保存实体或创建->编辑->保存操作，并且由于休眠，这些操作大部分时间由 ONE dao 管理，因为休眠与@manyto。 .. collection 和 cascade.save_update 允许在同一个持久化操作中保存两个或多个实体。

因此，例如，在我可以插入、编辑或创建项目（要出售的产品）的项目 JFrame 中，有：

这是我在大多数情况下所拥有的，所以我认为我陷入了贫血域反模式......

谢谢。