EJB 是包级、类级或方法级机制

Question

当我在这里说"EJB"时，我的意思是EJB 3.x！

我是 EJB 的新手，想知道如何最好地将所有业务逻辑映射到不同的 bean。在一个极端，你可以 KISS 并且只有一个整体式 EJB，它有无数种方法可以处理 100% 的应用业务逻辑。在另一个极端，您可以将业务逻辑分区到功能级别（List<User> getUsersFromMars()），并拥有无数个 EJB，每个 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 处理与单个（域）实体（如客户）相关的所有操作。它仅与数据源（通常是数据库）交互，并且具有保存，更新，删除等方法，以及getBySomething方法。这样的 DAO 通常可以有 1 到 ~15 种方法，具体取决于您的特定业务案例。

然后，根据经验，您拥有与 1 个以上实体交互和/或与其他系统（如 JMS 队列、邮件系统、Web 服务等）交互并执行验证/提供安全性的服务。这些构成了业务逻辑的动词，通常围绕特定的业务概念（例如购买）集中。因此，您可以有一个假设的PurchaseService，使用purchaseGood，purchaseOffer，calculateReduction等方法。同样，这将有 1 到 15 或 20 个方法之间的任何位置。