Expert One On One J2EE Development Without EJB
The Way Forward
This book is not primarily about questioning EJB, but about mapping a path forward. This includes architectural principles, working code, and practical advice you can use in your projects today.
The way forward that this book proposes is to focus on core values—Irsquo;ll call them themes—that help lead to project success, and to examine architectures and implementation choices that express them.
Themes
The central themes of this book are:
❑ Simplicity
❑ Productivity
❑ The fundamental importance of object orientation
The primacy of business requirements
❑ The importance of empirical process
❑ The importance of testability
Letrsquo;s briefly discuss these.
Simplicity
There are simple problems, and architecture and implementation should always be as simple as possible.
As Irsquo;ve already mentioned, J2EE projects are often over-engineered, partly because of an assumption that J2EE applications are necessarily complex. This isnrsquo;t always true. Areas in which J2EE architects often assume requirements to be more complex than they are include:
❑ Database distribution. Many applications use only a single database. This means that they donrsquo;t need JTA, two-phase commit, or XA transactions. All these high-end features incur cost in performance and complexity.
❑ Assumption of multiple client types. An application may have a requirement for a web interface. But J2EE architects are also likely to assume that it must also be able to support remote Swing clients. The assumption that all J2EE applications should be able to support multiple client types is deeply ingrained. (Indeed, I only realized that itrsquo;s actually not that common when a reviewer on one of my previous books pointed it out, prompting me to reflect on real projects Irsquo;d been involved with.)
J2EE orthodoxy in both cases is that the user isnrsquo;t allowed to have such simple requirements. We J2EE architects, in our wisdom, know that the clientrsquo;s business will get complicated enough to justify the complexity wersquo;re going to make him pay for up front.
There are two problems here. Firstly, including this complexity isnrsquo;t our choice as architects and developers, as we donrsquo;t write the checks. Secondly, even if the more complex requirements do ultimately emerge, how do we know itrsquo;s cheaper to factor them in from day one? It may well be cheaper to wait until these requirements come up. Itrsquo;s quite likely they wonrsquo;t; if they do, we can cross that bridge when we come to it. For example, the eventual remote client choice might be C# or VB.NET on Windows; an EJB-based remoting architecture might not be the best choice to support this. One of the key lessons of XP is that it is often more cost-effective, and more likely to produce a quality implementation, not to try to solve all conceivable problems up front.
We should minimize complexity up front to whatrsquo;s necessary to support actual (and reasonably foreseeable) requirements. However, it is necessary to design a simple architecture that allows for architectural refactoring to scale up. Refactoring an architecture is not as simple as refactoring code; clearly we donrsquo;t want to have to scrap much of our code to meet additional requirements.
Itrsquo;s important to have a simple architecture that can scale up. Itrsquo;s not so good to have a complex architecture, such as an EJB architecture, that canrsquo;t scale down to meet simple requirements.
In my experience, the keys to enabling architectural refactoring in J2EE projects are:
❑ To follow good OO design practice and program to interfaces rather than classes. This is a fundamental teaching of the classic Design Patterns text, and too often neglected.
❑ To conceal technologies such as EJB behind plain Java interfaces.
The architectural approach and frameworks discussed in this book make it easy to practice these principles.
Productivity
Productivity is an immensely important consideration, too often ignored in J2EE.
J2EE has a poor productivity record. J2EE developers typically spend too much of their time wrestling with API and deployment complexity when they should really be concentrating on business logic. The relative proportions are better than in the CORBA days, but still not good enough. Much of this incidental time is associated with EJB.
The approaches advocated in this book are highly productive, partly because theyrsquo;re comparatively simple and dispense with a lot of unnecessary crud.
OO
Surely, since Java is a rather good OO language, object orientation is a given for J2EE applications? While it should be, in fact many J2EE applications are really “EJB” or “J2EE” applications more than OO applications. Many common J2EE practices and patterns sacrifice object orientation too easily.
OO design is more important than specific technologies, such as J2EE. We should try to avoid letting our technology choices, such as J2EE, constrain our ability to use true OO design.
Letrsquo;s consider two examples of how many J2EE applications sacrifice OO:
❑ The use of EJBs with remote interfaces to distribute business objects. Designing an application in terms of distributed business objects with remote interfaces can deliver a fatal blow to OO. Components with remote interfaces must offer interfaces designed to avoid the need for “chatty” calling for performance reasons, and raise the tricky problem of marshaling input and output parameters in terms of transfer or value objects. There are applications that must offer distributed business objects, but most shouldnrsquo;t and are much better off staying away from this
剩余内容已隐藏，支付完成后下载完整资料
不包含EJB的J2EE架构开发
未来的方向
这本书主要不是怀疑EJB，而是寻找前进的道路。这包括你可以使用到的架构原则，工作代码，给你的你的项目提供的实用建议。
主要内容
这本书的中心主题是：
- 可行性
- 生产力
- 面向对象的基本重要性:业务需求的首要地位
- 经验过程的重要性
- 可测试性的重要性
接下来我们开始讨论
可行性
有一些简单的问题、结构和操作的方法应该尽可能的做到简化和方便。
正如我前面提到的，J2EE项目往往重复设计，虽然一部分是确实因为J2EE应用程序必然是复杂的，但这并非总是如此。在J2EE工程师经常假定需求方面比他们实际中的更复杂。
数据库的分布。
许多应用程序只是一个独立的数据库。这意味着它们不需要JTA，俩个阶段的部分，或XA事务处理。所有这些高端功能招致性能和复杂性成本。
多个客户端类型的假设
一个应用程序可以具有用于一个网络接口的要求。但是J2EE工程师也有可能假定它也必须能够支持远程控制客户端。因此所有的J2EE应用程序应该能够支持多个客户端类型是常用的假设。 （事实上，我才意识到这不是共有的直到我新书的一个评论者指出来的时候，我才开始反思我之前做的项目。
在这两种情况下的J2EE中，用户普遍是不允许有这种相似的要求。我们J2EE架构设计师通过我们的智慧，了解到客户的业务将得到怎样复杂的程度，在这之前我们了解到项目大小并让其付款。
这里有两个问题。首先，包括这种复杂性是不是我们的选择，而是架构师和开发商，我们不能写支票。没有实际的作用，其次，即使在复杂的要求最终出现的时候，我们怎么知道它如何简单易行的实现，这可能是更容易的等到这些要求实现。这是很可能他们不会;如果他们这样做，我们可以当我们遇到这种情况时这么去做。例如，最终的远程客户端的选择可能是C＃或VB.NET Windows上;基于EJB的远程化体系结构而不支持此的最佳选择。XP的关键教训是花费了更多的消耗，更容易产生质量实行，而不是试图解决所有可能的问题在前面。
我们应尽量减少在架构的复杂度，只为现实的（和合理的可预见的）需求提供技术支持，不要试图预先把所有问题都提前空滤进去，但是在力求简单的情况下，有必要多留意架构的设计质量以保证在未来能够对其进行重构，使其满足应对更加复杂的需求，对框架的重构不像重构代码那么简单，但虽然我们不希望面对新的需求使被迫大量代码，就必须重视架构的重构。
拥有一个可以眼神的简单架构是至关重要的。毕竟我们办法我们没办法裁剪EJB这样复杂的框架来构成简单需求。按照我的经验，使J2EExian项目具备关键架构重构能力的关键在于：
遵循良好的OO设计法则，并且最终针对接口编程，而非针对类编程。这是Design Patterns教给我们的基本常识，可惜人们常常忽略了这一点。将EJB之类的技术隐藏在普通的java对象背后。本书所讨论的架构方法和框架使得开发者更加容易实现这些原则。
生产率
软件的生产率是一个极其重要的问题，但是J2EE的正统思想常常忽略了这一点。J2EE在提升生产率的过程中做的并不完美，J2EE开发者常常要用大把的时间来与API和复杂的部署问题周旋，而在这些时间本该用来处理业务逻辑的，和使用CPRBA的日子相比，J2EE的生产率有所提高，但仍然无法令人满意，在这些被浪费的实践中有很大一部分是与EJB相关的。
本书所推荐的方案相关的生产率很高，这在很大成熟上是因为这些方案比较简单，略去了许多不必要的负担。
OO
当然了，我们要OO，不过，既然java是一种相当好的OO语言，难道J2EE不是面向对象么？他们是，但实际上很多J2EE应用仅仅是”EJB应用“，或者“J2EE应用“，而不是OO应用。很多常见的J2EE实践和模式过于轻率地背叛了面向对象的原则。让我们考虑有多少J2EE应用程序的牺牲OO的两个例子：
远程接口的EJB上使用分布式业务对象。在远程接口分布式业务对象来设计一个远程端口，其分布能力是对OO的严重破坏。与远程接口的组件必须提供设计，为了避免对性能方面的原因“繁琐”，使用有必要接口，提高传输或值对象的形式编组输入和输出参数的棘手问题。有迹象表明，必须提供分布式业务对象的应用程序，但最不该和好得多从这个特殊的地区删除。这个问题并不是EJB独有：EJB不是第一个使用分布式对象技术，这个之所以连与EJB在一起，是因为与EJB的分发组件是一件事，使EJB简单：但是似乎好过头了。
认为持久对象不应该包括任何行为。很长时间以来，这一直是J2EE开发者不容置疑的信条。包括我本人也曾迷信过他，但自从这本书出版以后，我的思想发生了一些变化，这便是其中大转变之一。其实J2EE的开发者们之所以会有这样的信条，更多的是因为entity been技术上严重的缺陷，而不是什么所谓的设计原则。仅仅是暴露getter和setter(例如，通过getter和setter暴露持久化数据)的对象不是真正的对象，一个真正的对象理应把针对自己状态的行动封装起来，使用entity been会促进开发者把这种缺陷看作一种规范的做法，因为entity been中的逻辑业务很难测试，而且不可避免的与特定的持久化策略捆绑在一起。例如，如果业务逻辑的显著量在实体bean的编码，很明显，要实现足够的性能的唯一方法是使用SQL和JDBC进行关系数据访问，需要大规模的重构练习）更好解决方法是使用一个透明的持久性技术，如JDO VS休眠，这使得持久对象是他们如何实际上是持久的真正对象，很少或根本没有依赖性。
并且在实现OO真正的价值。有效的应用，能够OO提供非常高的代码重用和优雅的设计。
在这本书中，我们不会忘记OO的价值。我们将试图表明J2EE应用程序如何能面向对象。
需求之上
这应该是显而易见的，但应用架构应该由业务需求来驱动，而不是目标的技术。不幸的是，这并不总是J2EE中的情况。开发人员经常认为幻象的要求，如：
❑在一个应用程序中需要支持多个数据库的支持，前面已经讨论
❑需要零成本的能力移植到其他应用服务器
❑能轻松移植到另一个数据库很容易
❑支持多种客户端类型
所有这些都是潜在的商业的需求，但它们是否实际要求应为每个应用程序进行评估。使用其他技术的开发者，如.NET开发人员，往往不需要担心这种幻象的要求，这意味着有时J2EE开发人员花费只是因为他们的技术选择努力，如果没有一个足够的理由，我们不能因为客户的需求、
经验过程
我的妻子是一名医生。近年来，医学实践已经通过循证医学的上升的影响医疗模式产生了很大的影响：在治疗的决定在很大程度上受到来自医学研究证据的影响的模型。治疗决定通常是由对病人的病情的各种选择的已知结果的基础上。
虽然循证医学在医疗实践的影响可能不是完全积极的，这种经验法绝对有软件开发的经验教训
在迭代的方法过程中，这种做法被总结为可执行框架（来自RUP）、垂直切片或者穿刺方案。不管叫什么名字，总之要尽快搭建一个完整的、可执行的实例应用，以尽量减少采用此架构的风险，在这一过程中的目标是找出风险最大的架构风险，以尽量减少风险，这个过程是和核心用户故事来驱动，不管怎么样，这一过程必须与实际需求密切相关。如果采用敏捷式开发流程，要么我们会很自然地创建一个垂直切片，所以没有必要单独强调这一过程，我们就可以在他的基础上验证架构是否合理。其中重要的衡量标准：性能。可非功能性需求得到满足？这是J2EE，其中很多项目是不做早期的垂直切片结束了在最后一分钟棘手的性能问题拼杀最有可能的症结所在。
采用难度 被开发的时间和参与相称成本的要求实施？是结果的复杂程度相称的要求是什么？被魔法所涉及或过程重复？
可维护性
在这个垂直切片的基础上增加新的功能困难么，一个新手花费多长时间可以理解这个应用的架构和实现、并投入有效的开发。
可测性
测试开发的发展已经变得更加受欢迎，在过去的几年里，通常会产生令人印象深刻的结果。编写有效的单元测试的应用程序不仅仅是投入的时间和精力的问题;它可以通过高层次的结构受到严重的制约。在这本书中，我会强调架构，可以很容易地编写有效的单元测试。这是EJB的最大挫折之一。由于其EJB容器上的严重依赖，业务逻辑EJB编码是很难测试。
难以测试的代码通常也很难重新设计、再利用，在不同环境下，重构金额可测试性是敏捷项目的一个基本特点。以J2EE架构在这本书中阐述的方法是理想的敏捷项目，我们将讨论整个敏捷。
轻量级框架和容器
每个应用程序都需要一些基础设施，拒绝使用EJB并不意味着拒绝EJB所采用的基础设施解决方案。我们当然不想回到20世纪90年代后期，EJB出现之前的状态，为了开发复杂的java企业级应用，人们必须亲手实现资源池缓存、线程管理、服务定位、数据访问层和其他基础设施。
这本书将着眼于提供这种替代现有的框架。我们认为，这种替代的基础设施对成功的J2EE项目是必不可少的。因此，描述的功能和使用轻质框架，是这本书的核心部分。
在2003年似乎有这样的“轻量级”框架，它提供的业务对象和企业服务的管理没有EJB的重量级基础设施开花。这反映了对我已经提到过简单，重量更轻J2EE解决方案的运动。许多这样的框架，例如Spring，PicoContainer和nanning的来自繁荣java开源社区。我会说更多关于这个在第5章。
Spring框架
如果没有可用的，在真实产品中经过考验代码来展示我们介绍的架构方案，我们就不可能写出这本书。
Spring框架（www.springframework.org）是致力于为J2EE中的常见问题的简单，有效的解决方案，一个流行的开源产品。该项目从专家单对单的J2EE设计和开发公布的源代码早在2003年开发的，这是在提出一个综合的和雄心勃勃的应用程序框架寻常。春天，自购买一个欣欣向荣的开发者和用户社区变得更加全功能的防弹比任何我能独自开发。 （我的合着者，克林斯曼Hoeller，作出了实现这一点的春共同牵头作出了宝贵贡献。）的基本框架设计早于，甚至专家单对单的J2EE，是我的经验，在多个商业项目的结果。
在构思之初，我们并没有打算让Spring成为EJB的替代品，但他确实是为普通java对象提供了强大、可测试的的功能实现，让很多开发者能够在项目中使用EJB。
Spring并不是这个领域的唯一项目。这本书的设计业很少有Spring的设计。例如，我们主张用AOP来解决一些常见的企业问题;还有其他一些开源的AOP框架。大量 使用有质量的开源代码库的是这本书的真正区别。大多数J2EE书还随代码示例。不幸的是，代码的价值通常是有限的，因为它代表了所必需的教学目的，力图在实际应用中，应用代码时它迅速成为问题的问题的简化。因此说明利用点具体的，经过验证的框架，即使不是所有的读者都将与该框架，来阐述出只适合介绍简单的失去真实意义的解决方案，引起如此才能把整个解决方案放入书本中。
Spring为体系结构重组提供了技术支持，譬如说，你可以在应用框架中接入带有本书的EJB，也可得到业务对象添加AOP支持，而不必要修改任意一行调用代码，当然你必须遵守基本的编码规则针对接口编译，而不是针对类型编译。
我们应该永远使用EJB？
EJB仍然有他的位置。这本书介绍，提供更简单，更高效，可替代EJB对绝大多数的J2EE应用程序的方法。但是，我们并不认为这样的做法是所有问题的最佳解决方案。
EJB的问题是他违背了” 帕累托法则，为了满足少数情况下的特殊要求，他给大多数使用者强加了不必要的复杂性。比如说；也许只有10%的应用需要分布式的业务对象，然而EJB的基础结构却与对象分布式密切相关。EJB 2.1以前的entity bean被设计为与数据存储机制无关，但绝大多数J2EE应用使用关系数据库，因此他们能够entity bean存储机制无关性中几乎不能获得任何好处。（虽然它提供了数据存储之间的可移植性，它比实际值以下的理论兴趣的，它不与对象数据库闪耀任一，都使用他们自己的丰富的API，或使用诸如JDO溶液最好访问）。
EJB仍然为真正需要对象分布应用的最佳选择，特别是如果他们是在完全的Java实现，或者需要使用IIOP作为通信协议。这种类型的应用是罕见可能比想象的
EJB也是被周围的消息很大程度上基于应用的一个很好的解决方案，同时 entity bean是相对简单和有效成分。
EJB能够真正为项目提升价值的典型例子，或许就是金融中间件应用，金融应用中间件的处理过程常常需要大量的时间和计算能力，比起业务处理本身的开销，远程调用的开销常常倒是可以忽略不记了。而且，金融中间件也通常是面向消息的，很适合使用MDB。
当然也有可能是强大的政治，而不是技术，这决定了使用EJB的原因。这是这本书的范围之外。根据我的经验，政治斗争可能更难不是技术战取胜，你需要马基雅维里，而不是我作为指南..
小结
在本章中，我们大致浏览了一下本书后面各个详细章节的主题。从J2EE诞生之初，EJB就被视为J
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[153874]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
