Java Swing应用程序中的服务层

Question

我在考虑是否真的需要服务层。

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

最佳实践是，我必须编写服务以使用我的dao，并将所有交易管理都放入服务中。

但是我经常意识到，服务层仅复制dao方法，因此例如： 通用标签

这是服务层的典型用法... Hibernate与db无关，spring与tecnology无关：那么，我真的需要它吗？

如何管理所有DAO的唯一Service类呢？我认为这可能是一个不错的折衷方案，或者是不好的做法？

我知道将@Transactional放在DAO上是一种不好的方法，但是现在我只需要为其上的@Transactional写服务...

编辑

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

我的应用程序是一个管理软件，可以管理用户注册，产品，订单和其他类似内容。 实际上，它包含许多读取实体->编辑->保存实体或创建->编辑->保存操作，而且由于休眠，由于大多数情况下使用@manyto休眠，大多数情况下，这些操作由一个岛管理。 .. collection和cascade.save_update允许在同一持久操作中保存两个或多个实体。

例如，在我的项目JFrame中，我可以在其中插入，编辑或创建一个Item（要销售的产品）： 通用标签

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

谢谢。

Answer 1

如果您的服务层重复dao，则说明您根本没有使用服务层。我在少数几个应用程序中犯了同样的错误，我想知道“为什么服务层看起来如此丑陋，并且是重复的DAO” ...

服务层应该是您的应用程序的接口，这并不意味着在dao和服务中某些方法并不相同，但是主要部分存在很大差异。在不查看其余代码的情况下，我不能这样说，但是根据您的问题（与几个月前的问题几乎相同），在我看来，您正在使用贫血域模型反模式。在贫血症领域模型中，您的模型仅包含字段和获取器，没有真正的方法（行为），这违反了面向对象的基本原理（对象==数据+行为）...您的行为可能类似于服务中的事务脚本层，但应在您的模型（域层）中。

解决方法是使用富域模型（通过@Configurable注入到模型中的bean）。您可能会说，这违反了图层模式，您可能是正确的。但是我坚信，我们应该将我们的应用程序（域+ dao +服务）视为一个单独的组件（请参阅Alistair Cockburn 六角形架构/端口和适配器）。

您的swing应用程序/ Web客户端将成为核心组件的客户端，然后您可以不受任何限制地进行切换（因为所有可修改数据的内容都在核心中）。

但是这种方法存在局限性/缺点。如果您将通过休眠使用某种安全性（春季安全性）或活动记录，则应通过DTO（不是实体本身）与所有客户端进行通讯，因为当您联系实体时，它可能会调用服务，而服务会通过事务性的，并且可以修改数据库（绕过您的安全性）。

我希望，我已经猜到了您的体系结构，如果没有，我很抱歉在这里发明了轮子，但是这篇文章可能会对不知道这一点的人有所帮助（就像我几个月以前一样）。

编辑

进行编辑：即使在简单的CRUD应用程序中，也应在服务层进行某种操作-例如验证（不是验证“这是一个数字”，而是一些特定于业务的验证）。这不应该出现在您的视图中，因为如果更改它，将再次复制并粘贴它。当您查看代码时，应询问“如果我决定编写瘦客户端（在Web浏览器中查看）”，是否有任何代码需要复制？如果答案为是，那么您应该为此可能的远程呼叫创建服务方法。

您应该/可以在服务层上做的另一件事是授权化（是否允许该角色的用户删除此条目）。比起几乎所有实体，您都将需要有一个服务层，因为简单的用户应该能够编辑（删除）他的条目，但可能不应该删除其他用户。但是角色为admin的用户可以执行此操作。

示例代码（我的应用程序中的服务界面文章的一部分（春季安全性）： 通用标签

在评论服务中，每个人都可以将其评论保存到文章中。...

最后一点：如果您完全需要服务层，则应该考虑一下。当以一种不错的方式编写应用程序时，您的应用程序将在灵活性，可重用性和可维护性方面获得许多品质。但是编写它非常困难且耗时。如果您不想做所有这些事情（安全性，富域模型，从更多接口调用（更改视图实现）），则可以不用它：-）

Answer 2

有时，您的应用程序将需要一些业务逻辑。另外，您可能希望验证输入，以确保没有任何有害或不良要求。此逻辑属于您的服务层。

此外，有可能使您的DAO非常通用，以便您只有一种或两种变化不大的方法。这样可以减少每次您要添加/更改应用程序功能时对DAO类执行严重错误的风险。

DAO用于访问数据。该服务用于业务逻辑。将它们分开，从长远来看，您会更快乐。

Answer 3

最终，您将需要协调多个DAO之间的行为。您可能还会给您的业务规则带来一些复杂性（例如：如果[that]处于特定状态，则不要更新[this]）。这是服务层派上用场的地方。

也就是说，完全消除服务层在“技术上”没有错。当您最终决定需要一个时，会更加痛苦。

Answer 4

代替强制执行 通用标签

对于每个操作，请考虑同时允许两者 通用标签

后者用于更复杂的操作