Question

当我在这里说“EJB”时，我指的是EJB 3.x！

我是EJB的新手，我想知道如何最好地将我的所有业务逻辑映射到不同的bean。在一个极端，您可以KISS并且只有一个单一的EJB，它具有处理应用程序业务逻辑100％的大量方法。另一方面，您可以将业务逻辑划分为函数级别（List<User> getUsersFromMars()），并且每个EJB包含1个包，1个类和1个方法：

Extreme #1:
    my-ejb.jar/
        com.me.myorg.MonolithicBean
            List<User> getUsersFromMars();
            List<User> getUsersFromVenus();
            //... a bazillion methods

Extreme #2:
    my-mars-ejb.jar/
        com.me.myorg.MarsBean
            List<User> getUsersFromMars();
    my-venus-ejb.jar/
        com.me.myorg.VenusBean
            List<User> getUsersFromVenus();
    //... a bazillion EJBs with 1-and-only-1 method each

显然，我认为最佳实践决定了这两种极端之间的某种中间策略。所以我想问一下，Java / Oracle如何将应用程序的业务逻辑分解为bean，以及如何在正确的级别（EJB，包，类或方法）对它们进行模块化，以便可重用，可扩展且安全？

Answer 1

我认为这个问题并不是特定于EJB，而是更多关于OO设计，甚至是一般设计。

经常出现的模式是您可以将业务逻辑拆分为DAO和服务。 DAO处理与单个（域）实体（如Customer）相关的所有操作。它仅与数据源（通常是数据库）进行交互，并具有保存，更新，删除等方法，以及getBySomething方法。这些DAO通常可以有1到15种方法，具体取决于您的具体业务案例。

然后，您拥有的服务作为经验法则与多个实体交互和/或与其他系统（如JMS队列，邮件系统，Web服务等）交互并执行验证/提供安全性。这些形成了您的业务逻辑的动词，并且通常围绕特定的业务概念集中，例如，一项采购。所以你可以有一个假设的PurchaseService，有一些方法，比如purchaseGood，purchaseOffer，calculateReduction。同样，这将介于1和15或20种方法之间。

EJB是包，类还是方法级机制

1 个答案: