0

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

我是 EJB 的新手，想知道如何最好地将我的所有业务逻辑映射到不同的 bean。在一个极端情况下，您可以 KISS 并且只拥有一个单一的 EJB，它具有处理 100% 应用程序业务逻辑的无数方法。在另一个极端，您可以将业务逻辑划分到函数级别 ( List<User> getUsersFromMars())，并拥有由 1 个包、1 个类和 1 个方法组成的无数 EJB：

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、包、类或方法）将它们模块化，以便可重用、可扩展和安全？

4

1 回答 1

2

我认为这个问题并不是真正针对 EJB，而是更多关于 OO 设计，甚至是通用设计。

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

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

于 2012-07-04T17:36:50.073 回答