精通J2EE应用程序开发之交叉分析J2EE

　　企业应用程序 最后，我们了解一下“真正的”企业应用程序，它是以下三个层的多个 facet 的融合：表示层、逻辑层和数据访问层。传统的企业系统需要使用遍布多个应用程序、语言或平台的业务规则集合以各种格式显示多个资源中的数据。企业应用程序最具复杂性，而这正是 J2EE 的强项。此外，由于伴随复杂性而来的是强大的功能（和灵活性），因此表面上“过于复杂的”J2EE 规范及其关联技术变得更为合适。

　　例如，门户通常就属于此类别，这是因为它们通常需要在所有三个层实现多重性 — 对于表示层，体现在门户通常组合了公司各个部分（或部门，或不同的公司，甚至可能是不同的移动家庭）的不同 web 应用程序，对于业务逻辑层，体现在特定“portlet”有时将需要调用由不同的 portlet 的后端提供的功能，对于数据访问层，体现在大多数 portlet 拥有自身的用于交互的数据库（或数据库集，目的是使事物更有意义），但更有趣的是，给定用户的会话通常需要跟踪进程中的信息，即使用户在各种 portlet 之间来回移动。在许多方面，门户及其关联 portlet 是企业应用程序的典范。

　　 “在许多方面，门户及其关联 portlet 是企业应用程序的典范。”

　　它将我们至于何处？

　　此类分类本身就足够出色了，因此会让技术哲人们陶醉好一段时间，但这究竟与构建如今的企业 Java 应用程序有多大关系呢？

　　首先也是最重要的是，企业 Java 开发人员必须尽快确定他们被要求构建的应用程序属于以上五种应用程序的哪一种。如果是传统的烟囱系统，则选择哪种技术并不像其他四个应用程序那样重要。当出现 Web 服务问题时，将其看作是其他表示层（意味着您现在在查看珠宝应用程序）而不仅仅看作是 Struts 代码与业务逻辑之间使用的模型对象扩展。实际上，在很多方面，模型视图控制器模式是表示层本身的一部分，而并不是延伸到业务逻辑层的什么东西，这是因为执行有效的“不同”表示层通常将要求我们针对如何与后端交互进行不同的选择，如（对于 Web 服务）将系统的“面向对象”的本质抛在后面。