Posted on 2006-01-18 12:45
开源爱好者 阅读(324)
评论(0) 编辑 收藏 所属分类:
Spring
第 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/