BlogJava-Open-Open-随笔分类-Spring

轻量级开发

开源爱好者 — Wed, 18 Jan 2006 04:45:00 GMT

第 1 部分: 核心原则及原理

引用:

在轻量级开发中，您基本上可以：

* 合并过程、技术和原理。
* 优先选择较简单的技术。
* 在一个稳固、轻量级的基础上，进行构建。
* 尽量争取最可能的透明性。
* 使用您可以利用的技术，如依赖注入和 AOP。

http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight1/

第 2 部分: 如何减轻容器

引用:

现在，您已经大概了解了轻量级容器。您了解了以下的基本设计理论：

* 构建一个接受 POJO 的容器，而不是受限制的组件
* 使用依赖注入来松散、解析依赖性
* 使用拦截和 AOP，将服务与 POJO 相关联

http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight2/

第 3 部分: Spring 露出水面

引用:

Spring 的重大意义
对于那些使用 Spring 的人，Spring 无疑是革命性的。它的一些简单思想引发了影响深远的结果：

* Spring 有力地开拓了企业级服务容器。使您不再“隶属”于容器提供的 API 或服务。可以使用 Spring 上下文管理预打包的服务，整合第三方服务或自己编写服务。
* Spring 在可测试性方面有了长足的进步。通过 Spring，能够使用依赖注入将模拟对象插入到难以接触的位置，在容器外运行对象（因为这些对象是 POJO），甚至使用容器提供不可预知的数据。
* Spring 的胶水代码使得只要编写很少的代码就可以轻松插入企业服务。编写的代码越少，维护和扩展代码时工作量就越少。
* Spring 代表一个开放源码项目，重新定义了 Java 商业小组开发软件的方式。Spring 对于最新 EJB 规范的影响是不容置疑的，同时也是非常重要的。

http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight3/

第 4 部分: 轻量级容器的比较

引用:

哪一个最好？

目前，只有一个真正的答案。HiveMind 具有有趣的创新，PicoContainer 具有易于使用的模型（理论上），但社区似乎已经投票选择了 Spring Framework。随着时间的推移，新的容器可能会成长，HiveMind 可能不断获得市场份额，但目前，Spring 是您的最佳选择。

如果您愿意冒一些险，而使用不太成熟或不太流行的容器，您可能决定实现 HiveMind（如果需要模块级别的配置）或 PicoContainer（如果想要微小的容器）。如果需要许多胶水代码来集成持久引擎、事务处理策略和安全性等方面，Spring 具有最完整的组件堆。但请记住：您可以在 HiveMind 容器中使用 Spring 组件。

http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/
第 5 部分: 在保守公司进行敏捷开发

引用:

本文介绍合力完成一种不同的活动：应用程序开发。敏捷开发流程，比如极限编程（Extreme Programming，XP）和 Scrum，寻求降低流程开销。尽管存在许多不同的流程，但它们当中都有一些共同的趋势：

* 越来越重视客户参与，而非重量级需求文档
* 通过重构改进质量和设计；重的、自动化的单位测试；连续集成
* 小团队，较少的正式沟通和更多的非正式沟通（15 分钟的站立早会，更多的配对编程）
* 短而一致的周期，最后是客户反馈

敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。尽管许多编程人员理解轻量级、敏捷方法的强大功能，但许多管理人员习惯使用更传统的流程。如果您认为敏捷可以帮助您，那么通过应用下列思想来学习如何协调传统管理与敏捷开发流程：

* 将您使用的语言改为侧重于原则，而非流程。
* 创建小而灵巧的团队。
* 重视可测量的交付。
* 重视简约性。
* 重构代码并自动化测试。
* 获得客户反馈。

http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight5/

第 6 部分: 持久性策略

引用:

神话 1：技术总是最要紧的。

不论您是在谈论 RDBMS 还是持久性框架，持久关系都是长期的。您需要知道您选择的方案将长时间拥有市场份额。如果不是，您将冒着被迫离开指定框架的风险，而这并非您的意愿。
神话 2：对象关系映射程序（Object Relational Mappers，ORM）隐藏了所有的数据库问题。

持久性框架简化了一些问题，但引入了一些其他的问题。如果您不理解底层架构，那么找懂的人问，或者不要使用对象关系框架。
神话 3：JDBC 总是比 ORM 要快。

当然了，一个非常协调的特定 Java 实现总是会打败普通的 ORM，但是您很难找到一个非常协调的 JDBC 应用程序。JDO 和 Hibernate 之类的框架提供许多方法来提升性能。
神话 4：ORM 总是合适的工具。

常常，您会发现要求更好的访问 SQL 的问题。您也会发现面向批处理的而非交互式的问题，或要求直接访问数据库行，而非完整的对象模型。这些问题并没有充分利用 ORM。更糟糕的是，一些解决方案也许会碍事。
神话 5：Java 的 ORM 解决方案是处理持久性的惟一的好方法。

其他语言同样有具有竞争力的持久性策略。Microsoft® 策略倾向于接受关系数据库并与行集一起工作。您让应用程序与关系模式紧密结合，但是您获得了一种能力，可以绑定行集到用户界面控制，并整个应用程序中将它们与缓存策略集成，甚至脱离防火墙与缓存代理。Ruby 语言有 Rails，后者有一个有效的记录框架。对于许多类型的问题，记录框架比 Java 技术解决方案更加动态和高效。

http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight6/

第 7 部分: Java 替代方案

引用:

简而言之，Java 语言不是一种生产效率非常高的程序语言。创建者做了一些聪明的妥协来从 C++ 夺取控制权，但我们开始为那些妥协付出代价了。在 Beyond Java 一书中，我详细讨论了这些问题。我仍然为大多数的项目使用 Java 语言。很容易找到适合我需要的框架。我能很快地找到程序员和工具。它是一种经过验证的编程语言。我的许多客户有太多的遗留代码，修改起来工作量太大。

但是，我已经开始为某些已付项目使用不同的语言。对于大型关系数据库上的基于 Web 的用户界面，Ruby on Rails 是有效的。对于要求有限的可伸缩性和可用性但要求复杂导航的应用程序，Seaside 是有效的。许多语言处理丰富的客户端开发要比 Java 语言好。

我还发现，如果赢利较大，处于创业阶段的公司愿意承担更多的风险。如果生产效率是首要关心的问题，团队很小，并且您正在解决一个很适合于动态语言的问题，那么使用动态语言是很有意义的。通过迁移到一种更加动态的语言和一个更加适合项目的框架，我为一个客户节省了 60％的项目预算。通过迁移到一种技能要求没有 Java 语言那么严格的语言，我让另一个客户减少了 30％多的职员。

底线？有时，当考虑轻量级开发时，值得脱离 Java 语言看一看。在接下来的几篇文章中，我将离开 Java 语言来探索一种新的语言和几个轻量级框架。

http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight7/

Part 8: Seaside

引用:

In mid-1999, Tennessee rivers were low, but the Ocoee River was flowing well. As I approached a rapid called Hell Hole, I could see the other tourists shudder with fear, but I wasn't worried. In this massive raft, we had nothing to worry about. In fact, up ahead, a kayaker was playing in the hole, and his body slowly slid down, as if he were on an elevator. We passed over, and he came right back up, still surfing the hole. Strange and wonderful.

My raft might be bigger and safer, but there were things it just couldn't do. In his tiny kayak (called a playboat) he could surf the waters beneath the surface to do things seeming alien to those of us in the raft. The Seaside framework is like that. You wouldn't use it for all Web development, but under these circumstances, you might give it a try:

* You have sophisticated work flow and want to manage flow from one simple program.
* You don't want to stay with a safe, conservative language, like the Java™ programming language.
* You like Smalltalk or one of the Smalltalk dialects.
* You have a start-up company in which picking a productive technology is much more important than picking a fast one.

This article gives a high-level tour of Seaside. If you like what you see, you'll have enough information to dive deeper.

http://www-128.ibm.com/developerworks/opensource/library/os-lightweight8/

开源爱好者 2006-01-18 12:45 发表评论

Spring的巧妙之处

开源爱好者 — Wed, 18 Jan 2006 04:43:00 GMT

作者注：在《Better, Faster, Lighter Java》一书第八章的这份节录中，我们将看到一个使用Spring框架的企业web应用程序例子。尽管Hibernate提供了单个的服务，Spring框架却提供了一种高效地构建和汇编Java应用程序的方法，以及多种服务的抽象。尽管 Spring支持多种服务，但是它最受关注也是最出色的特性是杰出的分层和封装。与EJB一样，Spring的中心组件是一个容器；而且Spring框架也同样提供对核心J2EE服务的访问。但是这就是它们仅有的相似之处了。下面是一个比喻。

　　我喜欢皮划艇运动，也花了很多时间来教授皮划艇技巧。我的一个专长就是教授学生如何在浪花中翻转弄翻了的皮划艇。一天，我向一位四肢发达的大个子和一位玲珑瘦小、体重只有97磅的女士传授该技巧。当我在陆地上从头到尾仔细地讲述这项技巧的时候，大个子直勾勾的盯着远方，不感兴趣。而那位女士注意力集中，而且希望反复练习这项基础技巧。在半个小时之内，她就出色地完成了第一次翻转，而他只是上下摇摆，在平静的水面上拍打出细小的白色泡沫。直到第三个学时，他才完成这个动作。在以后的几个学时中，她依靠技巧快速提高，而他却单凭力量在水中挣扎。到了实践的时候，她翻转了皮划艇，而他却在游泳。程序员们，请记住：解决问题的最佳方式是依靠简单性和技巧，而不是蛮力。

Pet Store：一个反例
　　Pet Store J2EE应用程序是一个很糟糕的编程例子。它误导成千上万名J2EE开发人员构建出设计糟糕、性能低下的代码。它还是一个基准的争论焦点。 Middleware Company致力于制订比较J2EE和微软的.NET平台的基准。他们选择Pet Store的J2EE版本作为基准的基础。尽管他们很努力地调优，J2EE版本还是惨败给Microsoft .NET版本，因此导致J2EE设计备受批评。我不想针对这次惨败谴责什么。我有不同的看法。我坚持认为：利用J2EE（尤其是EJB）很难开发出整洁、高性能的代码。另一方面，Pet Store基准本身就会导致更大的问题。

　　基准纷争过后，很多人借助于更平易且更简单的技术来实现Pet Store。其中一种最强大且最简单的实现方法是Clinton Begin所使用的，他利用一个称为iBatis的DAO框架来代替全部的实体bean。Rod Johnson的团队将该应用程序转化为Spring，并且现在已经与Spring框架一起发布。以下是相关的一些细节：

Spring jPetStore应用程序包含在M4或更高版本的Spring中。
它是一种具有JDBC DAO层的数据驱动的应用程序。
它提供了Strut的替代前端以及Spring MVC框架。
它提供了两种不同的模型。最简单的模型使用单一数据库和简单JDBC事务。另一种模型可以跨多个数据库使用JTA事务管理。

在下面的部分中，我将演示具有MVC web前端和单个数据库中的简单事务的应用程序版本。我将重点讨论域模型、单数据库DAO层、单一事务以及Spring MVC前端。Spring网站上提供了大量的资源，可供希望深入研究的开发人员使用。

配置文件
　　了解Spring应用程序应当从配置文件开始，它显示了主要的bean以及应用程序如何将它们组合在一起。Spring配置文件在应用程序上下文中定义bean。将上下文看作是收集应用程序指定资源的一种便利方式。

　　很多J2EE应用程序借助单元素来了解诸如连接之类的应用程序资源。这种用途的单元素与很多Java开发人员经常使用的全局变量差别不大。 J2EE中的替代方案是一种称为JNDI的目录服务，但是对于许多常见用例来说它就是杀鸡的牛刀了。而Spring使用一种应用程序上下文。最初，需要在一个简单的XML文件中指定应用程序上下文，尽管也可以通过扩展Spring来接受其它类型的配置文件。以下是应用程序上下文中可能会包含的内容：

数据源
　　管理连接的Java类，通常在一个池中。

DAO层
　　如果应用程序使用了数据库，那么很可能需要隔离对DAO层数据库的访问。可以通过应用程序上下文来访问该层。

持久性管理器
　　每个持久性框架都有一个应用程序用来访问其特性的对象或工厂。对于Hibernate来说，它就是会话和会话工厂。而对于JDO来说，它就是持久性管理器工厂和持久性管理器。

事务策略
　　可以显式地声明希望在事务中使用的方法以及用于实施该策略的事务管理器。

事务管理器
　　J2EE中有很多不同的事务管理策略。对于单一数据库的应用程序，Spring允许使用数据库的事务管理。对于多个数据库或事务源，Spring允许使用JTA。可以将事务管理器保存在应用程序上下文中。

验证逻辑
　　Spring框架使用一种与Strut类似的验证框架。Spring允许像配置其他业务组件那样配置验证逻辑。

视图和控制器
　　Spring框架允许为视图指定控制器，并帮助用户通过控制器来配置导航路径。

　　jPetStore应用程序使用包含一个数据源、DAO层和一种事务逻辑的Spring应用程序上下文。用户定义XML文档中上下文的内容，该 XML文档列出了一系列bean。每一个XML配置文件都包含一个题头，其后是一系列组件和一个脚注。如下所示：

代码:

以上是构成应用程序上下文的bean。它们代表应用程序中的顶级bean。（它们可以创建不出现在配置文件中的其他对象或bean。）在本例中，我们会创建两个bean：MyFirstBean和MySecondBean。然后，通过指定MySecondBean作为字段myField的值，将它们关联起来。当Spring启动的时候，它会创建两种对象，并设置myField的值。当在应用程序上下文中需要它们的时候，可以根据名称来访问这两种对象。

　　我们来看一个更具体的实例。jPetStore应用程序为业务逻辑、数据层和用户界面提供了三种配置文件，每种Spring配置文件各自描述三者之一，如图8-2所示。

图8-2 jPetStore应用程序提供了分别与三个不同的层相匹配的Spring应用程序上下文

　　这些配置文件指定了域模型、数据层和表示层的上下文。例8-1展示了jPetStore应用程序的业务逻辑应用程序上下文的一部分。注意：为了简单起见，我将包名org.springframework.samples.jpetstore...缩写为jpetstore。

例8-1 applicationContext.xml

代码:

[1]
[2]
[3]
[4]

[5] class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

PROPAGATION_REQUIRED
PROPAGATION_REQUIRED
PROPAGATION_REQUIRED,readOnly

以下是对注释的解释：

　　[1]业务逻辑。这部分（包括所有粗体代码）包含核心的业务逻辑。验证和域模型都视为业务组件。

　　[2]验证器。这是Order的验证器。一旦用户提交Order格式，并发送到错误页面或order完成页面，Spring就会按照要求调用该验证器。

　　[3]核心业务实现。该类包含持久性域模型的核心实现。它包含以下所有的DAO对象。

　　[4]属性。每一个bean都具有自己的属性，这些属性引用定义在其他地方的bean。在本例中，bean属性是单个的DAO。每一个bean都定义在另一个Spring配置文件中。

　　[5]事务声明。这个bean指定了应用程序的事务策略。在本例中，应用程序使用在另一个Spring配置文件中指定的事务管理器。它声明了应当传播为事务的方法。例如，所有以insert开头的方法应当传播为事务。

　　简而言之，该配置文件就像一种粘合剂，将应用程序的业务逻辑粘合在一起。在文件中，您会看到一些对本身并未包含在配置文件中的bean（如： DAO对象）的引用。随后，您会看到其他两种配置文件，它们定义了一些遗漏的bean。其中一个配置文件指定了事务管理器的数据访问对象。另一个配置文件指定了用户界面所需的bean。最好将配置文件分离到不同的层中，这样就可以按照需要配置各个层。例如，可能需要更改用户界面的策略（比如从Spring MVC web更改为Strut），或者数据访问的策略（比如从具有单个数据库的DAO更改为具有JTA事务、跨两个数据库的DAO）。

　　如果需要实例化XML上下文文件中的bean，那么非常简单。例如，要访问context.xml文件中Customer类型的名称为myCustomer的bean，可以采用以下三个步骤：

1, 获取包含配置的XML文件的输入流：

代码:

InputStream stream = getClass( ).
getResourceAsStream("context.xml");

2,使用输入流创建新的Spring bean工厂：

代码:

XmlBeanFactory beanFactory = new XmlBeanFactory(stream);

3, 使用该工厂创建.xml文件中定义的一个对象：

代码:

Customer cust =
(Customer)beanFactory.getBean(myCustomer);

　　或者，如果希望Spring初始化一个上下文，然后抓取会话外观，可以使用以下代码：

代码:

protected static final String CONTEXT_FILE = "WEB-INF/applicationContext.xml";
Biz biz; // session façade

FileSystemXmlApplicationContext ctx =
new FileSystemXmlApplicationContext(CONTEXT_FILE);
biz = (Biz) ctx.getBean("biz");

　最好放开控制权。通常不必直接访问应用程序上下文。框架会执行该操作。例如，如果您正在使用servlet，那么Spring框架会为每一个 servlet提供一个上下文，并为所有servlet提供一个总体上下文。通常可以从中获得正确的上下文信息，随后您就会看到这一点。既然已经看到了表示jPetStore应用程序的配置文件，现在应该看看如何构建各个元素：

域模型
　　与本书阐述的原理相对应，该应用程序以图8-3中的透明域模型为基础。该域模型包含表示现实世界的各个对象之间的业务关系。Pet Store由包含项目的cart（购物车）和order（订单）组成。

图8-3 应用程序的中心是域模型。

　　应用程序表示了一个简单的宠物商店。它由一个包含购物车项目(cart item)的购物车组成，该购物车又填充了一个包含线项目(line item)的订单。项目(item)由按类别(category)组织的产品(product)组成。每个对象都是一个透明的业务对象，被实现为具有一些属性和业务方法的Java bean。例8-2展示了一个CartItem。为了简单起见，我已经去掉导入和包细节。

　　例8-2CartItem.java

代码:

[1] public class CartItem implements Serializable {

/*Private Fields*/

private Item item;
private int quantity;
private boolean inStock;

/*JavaBeans Properties*/

[2] public boolean isInStock() { return inStock; }
public void setInStock(boolean inStock) { this.inStock = inStock; }

public Item getItem( ) { return item; }
public void setItem(Item item) {
this.item = item;
}

public int getQuantity( ) { return quantity; }
public void setQuantity(int quantity) {
this.quantity = quantity;
}

[3] public double getTotalPrice() {
if (item != null) {
return item.getListPrice( ) * quantity;
}
else {
return 0;
}
}

/*Public methods*/

public void incrementQuantity( ) {
quantity++;
}

}

以下是注释的含义：

　　[1]Spring框架不会强迫组件继承Spring类。它们是完全透明的，并且如果进行测试或者情况需要，还可以驻留在容器的外部。

　　[2]每一个字段都使用get和set方法进行包装，以便Spring可以通过Java反射来配置他们。（Spring还可以通过构造函数来配置它们。）

　　[3]与很多EJB应用程序不同，在域模型中包含业务域逻辑非常有用。

　　我将这种模型称作passive。它完全由域外面的对象调用，并且仅与域中的其他对象耦合。注意，虽然它具有私有属性和公有字段，但是它不仅仅是一个值对象。它包含用于计算总价和增加数量的业务方法。这种设计使得该业务对象易于理解和重用，即使是在整体设计改进的情况下。当我们介绍持久性方面时，您就会看到该模型的其他部分。

　　下周，在这个摘录自《Better, Faster, Lighter Java》一书的Spring系列的最后一部分中，作者将讲述如何将持久性添加到Pet Store例子中，并讨论Spring框架中的表示逻辑。

原文出处: Demonstrating Spring's Finesse http://www.onjava.com/pub/a/onjava/excerpt/BFLJava_chap8/index.html

作者简介
Bruce A.ate是一名山地车手和皮划艇手，也是2个孩子的父亲。在闲暇时间里，他还是一名独立顾问。他住在德克萨斯州的首府奥斯汀。他编写了4本书，其中包括最畅销的《Bitter Java》一书，最近出版了《Better,Faster,Lighter Java》（O'Reilly）。
Alexander Ananiev是一个程序员、作者、导师和指导员，他专攻现实世界软件应用程序。

开源爱好者 2006-01-18 12:43 发表评论

Spring资源

开源爱好者 — Wed, 18 Jan 2006 04:05:00 GMT

开源爱好者 2006-01-18 12:05 发表评论