相关疑难解决方法(0)

前提

我最近阅读/观看了由Java Champion Adam Bien撰写的很多文章/视频,他主张使用古老但更新的 实体 - 控制 - 边界设计模式 JAVA EE> = 6.

利用CDI,EJB 3.1,JPA 2和其他JAVA EE 6功能,此模式应有助于创建更多面向业务的组件,更易于单元测试,并根据职责更高地分离关注点.

由于我使用了上面列出的所有功能,而且这种模式听起来非常有趣,我正在寻找它,看看ECB是否符合我的下一个项目要求.

到目前为止我得到了什么

在欧洲央行,每个逻辑实体分为三部分(如果我错了,请纠正我):

• 一个边界,一种强大的门面,只有类的访问之外.对于外部(如果我做对了),我们的意思是在应用程序之外,例如.远程客户端,在组件包之外,例如.我申请的另一部分;

• a(n可选)控制器,负责某种操作(例如,实体的验证);

• 一个实体,可以是一个纯粹的JPA实体,但也可以包含一些装饰/验证/(最小)业务逻辑.

例如,考虑有两个不同的实体(Orange和Apple),一个在它们上做CRUD FruitsManager的类()和一个对它们执行某些控制的类(FruitsQualityChecker).

直到昨天,它会像(OLD WAY):

com.foo.bar.business.FruitsService        /* CRUD    */
com.foo.bar.business.FruitsQualityChecker /* CONTROL */
com.foo.bar.model.Orange                  /* ENTITY  */
com.foo.bar.model.Apple                   /* ENTITY  */

Run Code Online (Sandbox Code Playgroud)

和欧洲央行一样,我会(新方式):

com.foo.bar.business.oranges.boundary.Oranges …

Run Code Online (Sandbox Code Playgroud)