java swing应用程序中的服务层

Question

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

我正在使用spring + hibernate用于桌面摇摆应用程序,此时我有gui/swing layer-> service layer-> dao layer.我只将spring用于@Transactional支持和IOC注入

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

但我经常意识到,服务层只复制dao方法,例如:

// a DAO example
@Repository
public class CustomerHibernateDAO extends BaseHibernateDAO implements CustomerDAO {

 public List<Customer> findAllCustomerILikeName(String name){
  return getSession()
   .createCriteria(Customer.class)
   .add(Restriction.ilike("name", name))
   .list();
 }
}

// Customer service to use this dao...
@Service
@Transactional
public class CustomerService {

 @Autowired
 CustomerDAO customerDAO;

 // Why i can't call DAO instead the service?
 public List<Customer> getAllCustomersByName(String name){
      return customerDAO.findAllCustomerILikeName(name);
 }

}

这是服务层的一个典型用法... Hibernate是db-agnostic,spring是技术不可知的:所以,我真的需要它吗？

如何管理所有DAO的独特服务类？我认为这可能是一个很好的妥协,或者,这是一种不好的做法？

我知道将@Transactional放在DAO上是一种糟糕的方式,但此时此刻我必须编写仅用于放置@Transactional的服务...

编辑

关于我的应用的更多信息.

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

因此,例如,在我的项目JFrame中,我可以插入,编辑或创建项目(要销售的产品),它有:

public ItemFrame(){
 // the constructor
 itemService=springAppContext.getBeans(ItemService.class);
}

public boolean validateForm(){
 // test if the gui is correctly filled by user
}

public boolean save(){
 // create an Item entity taking value from swing gui(JTextField etc)
 Item item=new Item();
 item.setName(nameTextField.getText());
 item.setEtc...
 // ItemService ' save method is a wrap around itemDao.save(item)...
 itemService.save(item);
}

private void saveItemActionPerformed(ActionEvent evt){
 // When i press SAVE button
 if(validateForm()){
  save();
 }
}

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

谢谢.

Answer 1

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

服务层应该是您的应用程序的接口，这并不意味着dao和service中的某些方法不一样，但主要部分有显着不同。如果不查看您的其余代码，我就不能这么说，但是根据您的问题（这与我几个月前的问题几乎相同），在我看来，您正在使用贫血域模型 antipattern。在贫血域模型中，您的模型仅包含字段和获取器，没有真正的方法（行为），这违反了基本的面向对象原则（对象==数据+行为）......您的行为可能看起来像服务中的事务脚本层，但应该位于您的模型（域层）中。

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

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

但这种方法有一个限制/缺点。如果您将使用某种安全性（Spring安全性）或通过hibernate的活动记录，那么您应该通过DTO（而不是实体本身）与所有客户端进行通信，因为当您联系实体时，它可能会调用服务，该服务将通过以下方式激活自身：事务性的并且可以修改数据库（绕过您的安全性）。

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

编辑

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

您应该/可以在服务层上做的另一件事是授权（是否允许具有此角色的用户删除此条目）。您必须为几乎所有实体提供一个服务层，因为简单用户应该能够编辑（删除）他的条目，但可能不应该删除其他用户。但管理员角色的用户可以执行此操作。

示例代码（我的应用程序中的服务接口（Spring security）文章的一部分）：

@Secured("ROLE_EDITOR")
public void save(ArticleDTO selectedArticle, ArticleDetailsDTO selectedArticleDetails);

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

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