Gavin 指出 他不理解业务逻辑和UI之间的分离。这引发了为什么我们最初要进行层化的疑问。我听说过很多很多为了证明层化合理而提出的糟糕理由。实际上，这在我进行培训时是我最喜欢的问题之一。看到人们为了证明合理性而紧张的样子总是很有趣。
层化试图解决什么问题
- 关注点分离
- 更容易维护
- 松散耦合
- 可重用性
- 在组织中证明又一层额外管理的合理性
那么，这样的静态水平层可能存在什么问题呢？
- 它们之间的区别可能模糊，并导致餐厅中无休止的细枝末节讨论
- 它们自然地强制在层之间进行状态转换和状态传输，以实现隔离。状态转换和状态传输难以解决，速度慢，导致重复和维护噩梦：我的松散耦合去哪里了？
- 它们一半的时间没有真正的目的，只是为了取悦架构之神，成千上万的无意义和空白的类被编写来填充层，实现 delegation patterns 的 delegation patterns。
在标准意义上的水平（静态）层化（表示层、服务层、组件层、DAO层）是从那些黑暗的日子继承的概念，
- 组件模型膨胀且无法使用
- 无状态应用程序是黄金目标，因为“它扩展得更好”
我们需要一种方法来定义动态可重用的关注点，它们之间的交互，避免不必要的状态复制和重复，并找到关注点之间更自然的边界。如果组件模型由表示层、业务层和数据访问层技术共享，并且没有盲目的边界，它就能实现这一点。
现在，请稍等一下，想象一下你有一个轻量级组件模型，其中组件可以以强耦合和松耦合的方式相互依赖，组件可以通过发送事件相互交互，组件可以持有状态，并且其生命周期将自动处理。
一个组件将描述并实现业务需求
@Component
public class Checkout {
它将依赖于其他业务组件
@Component @Asynchronous @PayByCheque
public class ChequePaymentProcessor implements PaymentProcessor {
以自然形容词描述依赖关系及其要求，以松耦合和类型安全的方式
@In @Asynchronous @PayByCheque PaymentProcessor
它可以具有声明式行为
@Transactional @Component
public class Checkout { ... }
它可以通知其他业务组件
@In @Notifier @New Event<Order> order;
其他组件可以以松耦合的方式监听这些事件
@Component
public class AuditAgent {
public void onOrder(@Observes @New Order order) { ... }
}
哦，最后，它将是简洁的（检查之前的示例 :) ）
当然，一些组件可能比业务导向的更技术化，一些可能更DAO化，其他可能更Service化。但关键是这种组件模型以及描述与其他组件交互的声明式松耦合和类型安全方式非常灵活，并能满足您的需求。它符合您的需求，您必须适应它。
那么我们有什么呢？
- 关注点的分离：松耦合和声明式交互和行为
- 易于维护：类型安全和无状态传递
- 松耦合：接口/实现运行时和类型安全绑定
- 可重用性：一个组件代表一个用例，一个应用程序的故事
- 为组织中的另一个管理级别提供理由：如果您真的坚持，我们可以找到一种方法
Seam 为组件描述整个系统中的共享故事铺平了道路，而 Web Beans 将通过 Guice 的优雅类型安全声明式触摸来实现这一点。
