Question

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

我正在使用spring + hibernate用于桌面摇摆应用程序，此时我有gui / swing layer-＆gt; service layer-＆gt; dao层。我只将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是数据库不可知的，spring是技术不可知的：所以，我真的需要它吗？

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

我知道在DAO上放置@Transactional是一种糟糕的方式，但此时我只需要为它放置@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和服务中并不相同，但主要部分是显着不同的。我不能在没有查看其余代码的情况下这样说，但是根据你的问题（几乎与我几个月前的问题几乎一样），在我看来，你正在使用anemic domain model antipattern。在贫血领域模型中，您的模型仅包含字段和getter，没有真正的方法（行为），这违反了基本的面向对象原则（对象==数据+行为）...您的行为可能在某些看起来像服务中的事务脚本图层，但应该在您的模型中（域图层）。

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

您的swing app / web客户端将成为您的核心组件的客户端，然后您可以无任何限制地切换它们（因为所有modiefies数据都在核心）。

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

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

修改

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

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

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

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

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

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

Answer 2

在某些时候，您的应用程序需要一些业务逻辑。此外，您可能希望验证输入以确保没有请求恶意或不执行的内容。此逻辑属于您的服务层。

此外，有可能使您的DAO非常通用，因此您只有一两个方法不会发生太大变化。每次要添加/更改应用程序的功能时，这都会降低为DAO类做出严重错误的风险。

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

Answer 3

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

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

Answer 4

而不是强制执行

ui -> service -> DAO

对于每个操作，考虑允许两个

ui -> DAO
ui -> service -> DAO

后者用于更复杂的操作

java swing应用程序中的服务层

4 个答案: