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

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

最佳实践是我必须编写一个服务来使用我的 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 与数据库无关，而 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();
 }
}

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

谢谢。

最佳答案

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

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

解决这个问题的方法是使用丰富的域模型(通过@Configurable 将 bean 注入(inject)到模型中)。你可能会说，这违反了图层模式，你可能是对的。但我坚信，我们应该将我们的应用程序(域+dao+服务)视为一个单独的组件(参见 Alistair Cockburn Hexagonal architecture/Ports and adapters)。

然后，您的 swing 应用程序/网络客户端将成为核心组件的客户端，然后您可以无限制地切换它们(因为修改数据的所有内容都在核心中)。

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

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

编辑

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

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

示例代码(文章服务接口(interface)在我的应用程序(Spring 安全)中的一部分):

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

在评论服务中，每个人都可以将他们对文章的评论保存....

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

关于java - java swing应用程序中的服务层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4270461/