精通J2EE应用程序开发之交叉分析J2EE - 编程入门网
| 的图像 — 它们构成了一条垂直线，不由使人想起将燃烧木头的火炉中产生的烟排出到房间外面的旧式“烟囱”。（顺便说一下，对于将该术语用作贬义术语的用户而言，请记住，您在一生中将使用的许多最重要的系统（如 ATM 机、主要船运公司场地上的包裹定位器等）都是烟囱系统。
有一点可能比较令人吃惊的是，J2EE 软件套件并不能完全满足构建简单烟囱系统的开发人员的需要。当只需要一个表示层，且只有一个资源用于存储和检索数据时，J2EE 套件（尤其是 EJB）就显得“碍事”了。更诱人的方法是考虑轻型框架，因为它们并不那么专注于部署描述符，并且就 JNDI、JMS 之类而言也没什么不便的。它只是通过 web 浏览器进行的基本请求/响应通信，通常构建在类似 Struts 或相似的 MVC 样式 web 框架中，并与一组核心的传统 Java 对象（有时与单个机器上运行的表示层和业务逻辑层（而非数据库本身））进行通信。（您可能奇怪此处为什么没有使用术语“数据库”。原因很简单，虽然大多数项目使用数据库（而且还是关系数据库）存储数据，但数据存储通常是原有系统、商业软件程序包或形如 CICS 大型机、SAP 或 BizTalk 的“中介”技术。使用更一般的术语“资源”有助于强调这样一个看法：后端实现确实与本讨论无关。） 烟囱应用程序的另一个优势是它们通常是“独立的” — 也就是说不涉及其他应用程序。几乎不需要遵守任何已建立的安全、可靠性或管理标准，这是因为此应用程序所确立的所有内容都将成为标准（至少对此应用程序而言是这样，这正是此范围的关键所在）。开发人员经常利用此事实来构建正好适合于此应用程序的基础架构，从而消除了通常针对企业 Java 应用程序的指责：它们太复杂了，以至于无法使用和维护。 尽管人们希望如此，但 J2EE 的设计并非是针对烟囱应用程序的 — 当然，一个基于 J2EE 的应用程序可以构建此类应用程序（并且有上千个示例可以作为此事实的证据），事实上有点像用牛刀杀鸡。基于 J2EE 的应用程序实施了一定程度的层划分，但有时这种划分对于解决手头的问题显得有些矫枉过正，如传统的“10 用户”烟囱系统。当然，问题是 10 用户烟囱系统通常有一种另人不悦的趋势，即转变为其他四个版本中的某个版本，这样将使事情变得很糟。就像某位哲学家说的那样“没有哪个人是孤立的”，我们也可以很轻松和准确地说“没有哪个系统是孤立的”。至少在短期内是这样。（当然，如果系统无法完成其预期的目标，那它就无法与任何其他系统集成，并且可能停产，但我们将假设那不是预期的目标。） 珠宝 我们并不是说这是 IT 环境的成功和骄傲或五种应用程序样式中“最好”的一个，但珠宝样式的应用程序是结合了多个表示层的应用程序（因此，它的名称--“珠宝”表示有很多面可供查看）。但请注意，给定表示层可能根本不是供用户查看的；公司当前经常探讨的一个层是其基于 Web 服务的应用程序前端，它并非为人使用而设。尽管如此，该 Web 服务仍表示一个表示层，这是因为它从根本上执行同一操作：获取输入并从其下面的核心业务逻辑层中提供输出。 由于一度曾存在的某些假设突然间不复存在了，珠宝应用程序对传统编程模型进行了一些有趣的转变。例如，当考虑一个 Web 服务前端时，突然必须以某种平台和语言无关的方式（对此，XML 模式是当前可以选择的工具）定义类型，而理想情况下，“一次且仅此一次”规则（也称作“不重复自身”原则）将允许我们直接通过基于 HTML 的表示层用来与业务逻辑层通信的同一类型构建此类型。这就是某些 JAX* 规范的用武之地--例如，Java API for XML B |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
