【问题标题】:Service layer in java swing applicationjava swing应用程序中的服务层
【发布时间】:2011-05-15 07:15:59
【问题描述】:

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

我正在将 spring + hibernate 用于桌面 Swing 应用程序,此时我有 gui/swing 层->服务层->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 与 db 无关,spring 与技术无关:所以,我真的需要它吗?

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

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

编辑

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

我的应用程序是一个管理软件,管理用户注册、产品、订单和其他类似的东西。 在实践中,它包含许多读取实体->编辑->保存实体或创建->编辑->保存操作,并且由于休眠,这些操作大部分时间由 ONE dao 管理,因为休眠与@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 层,+1 btw跨度>
  • 如果数据库发生变化而我没有使用服务,请问有什么问题?我将重建我的 DAO,一切都很好……还是不行?
  • 我在这里有点跑题了,但是在 ItemFrame 构造函数中自己从容器中获取 bean 的原因是什么?我看不出这种方法比让容器注入 bean 有什么好处。
  • ItemFrame 是由 new ItemFrame() 实例化的,它不是弹簧组件,所以 @Autowired 在这里不起作用。我是春天的新手,但这是我所知道的......我希望它是正确的。
  • 这是有道理的。谢谢你的解释:)

标签: java hibernate spring swing service-layer


【解决方案1】:

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

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

【讨论】:

    【解决方案2】:

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

    此外,有可能使您的 DAO 非常通用,这样您就只有一两个变化不大的方法。这样可以降低每次您想要添加/更改应用程序功能时对您的 DAO 类造成严重错误的风险。

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

    【讨论】:

      【解决方案3】:

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

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

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

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

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

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

      编辑

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

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

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

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

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

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

      【讨论】:

      • 谢谢你很有用,我在我的第一篇文章中添加了更多信息,请留下评论!谢谢!
      • 我的实体只包含 getter 和 setter,但我的 daos 包含比 CRUD 更多的方法,因此它们是真正的存储库(根据 DDD,驱动域设计)。当我写实体时,我总是尝试以 OO 的方式思考。所以我混合了贫血模型和域模型。
      • 很好的链接,我不知道 Fowler 有一篇关于此的文章。
      【解决方案4】:

      而不是强制执行

      ui -> service -> DAO
      

      对于每个操作,都考虑允许两者

      ui -> DAO
      ui -> service -> DAO
      

      后者用于更复杂的操作

      【讨论】:

        猜你喜欢
        • 2016-02-05
        • 2012-09-13
        • 2012-09-29
        • 2014-06-06
        • 1970-01-01
        • 2011-08-06
        • 2015-07-23
        • 1970-01-01
        • 2011-05-05
        相关资源
        最近更新 更多