Facade类中的业务逻辑?

时间:2016-06-02 10:20:45

标签: java design-patterns facade

我们有一个关于建筑的(存在主义)问题。

我们来到了一个使用Struts1,Spring,Hibernate设计的项目。 Service Locator,Delegate& amp; Facade Pattern公开服务。服务有自己的DAO,可以调用其他服务。 DAO不会返回域名模型,但有些DTO :(

我们无法改变应用程序的理念。 但现在我必须开发一个新的功能域。

我们必须开发一个导入功能,其目的是经典:

  • 创建一个持久存储到数据库
  • 的文件夹A.
  • 通过阅读CSV
  • 创建链接到该文件夹​​的一些导入B.
  • 创建在第三个表C
  • 中读取的所有行

当然,还有另一个功能,即根据文件夹A的导入B计算一些信息。

所以,有一个Facade有2个服务:

  • 用于管理文件夹A的X服务
  • 用于管理导入的Y服务 乙

通常在Facade中,每种方法只调用一种服务方法。

考虑到我们在参数中有DTO,我们必须重新附加bean。 因此,X服务中的函数调用Y服务来获取导入。 但是Y服务中的导入函数调用X服务来获取文件夹信息,并在保存导入之前重新附加bean。

不知道我的英语水平是否很清楚(对不起)

但是,问题是所有弹簧配置都是在没有单件的情况下完成的。所以X调用Y,调用X是一个递归声明....

如何解决?

Facade只是一个将一些服务组合在一起的类,只用一个类来公开所有方法吗?

或者我们可以编写业务逻辑吗? 换句话说,是否有可能创建一种调用服务X& amp;是和管理所有代码呢?并且可能抛出一个BusinessException ......

0 个答案:

没有答案