• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

         这里所谓的企业级应用，就是Martin Fowler的企业应用架构模式中论述的企业级应用。

         在软件工程过去的40年里，虽然没有任何一种方法论能够达到舍我其谁的程度，但是确实在工业界和学术界达成了一些共识：封装，行为优先于数据考虑，依赖于抽象而非具体，迭代开发，领域驱动设计……而OO范型是这些最佳实践的最好集合。

         软件的设计，来自对于问题域的抽象，随着对于需求的理解深入，我们的设计会随之演化。结构化范型中首先设计数据库，我认为过早的对问题域进行了数学抽象，往往那些抽象过于远离问题域，它代表了当时对于问题域的理解。而数据库又属于依赖的最低层，这种不牢靠的抽象必然会造成设计的不稳定，因此从本质上讲，这种方法就是不可靠的。而OO可以直接去模拟业务领域，可以尽可能的去贴近实际。因为实际业务运行良好，那么你所设计的模型也会更容易的运行良好。我发现越是贴近现实领域的建模，其进化性越好。

       问题领域中不仅包含实体，还包含值对象，服务[Evans03]，而数据库建模则往往只强调实体。那么其他有用领域概念就在设计中丢失了。制作大而全的对象是不切实际的，对象属性和行为的确定要来自于业务需求，对象使得添加和减少属性和行为都变得容易。

       把一些行为和数据按照主题加以分类，写到不同文件里，就像我们写文章需要划分段落一样，每个段落表达一个意思，如果想补充表达某个意思，就去相应的段落扩展。而类就是这一个个段落。当某个段落表达了不同的意思，就按不同的意思分解。我想这和单一职责原则是有同构性的。那一个个函数就像一个个句子，面向过程设计将这些句子按照应用分布在应用中，而面向对象设计奖这些句子按主题分布在具有业务语义的类中。

     企业级应用的特点是：复杂和多变。一个复杂的东西在变是最让人痛苦的。于是尽可能要把它分解为小而简单的东西，让每个变化只局限于一个方面。

     某些东西是不容易变化的，比如商业，申请服务，提供/享受服务，结帐，这个大方向是不会变的。商业的一个子集，餐馆，上千年了，基本流程还不是点菜，上菜，买单？菜和帐是千年不变的实体。

     无疑，OO比数据库建模向前又走了一步。

      做了几个大型系统，和一些需求模糊、变化无常的项目，真找不出什么理由，做企业级应用可以不用OO。

     2008年4月10号补充：但是，现实情况却是，很少有项目采用OO范型，人们认为无论什么方法都不可能彻底解决企业应用核心复杂性（即问题域复杂），转而走向干脆不尝试OO。特别是在这个行业混迹多年、并且在学校只学了结构化方法的人。我与几个公司的信息部的人聊天，他们采用的方法都是先设计数据库，然而我用OO为系统添加了一项功能（我们为他们公司开发了系统，然后我去添加新功能），他们对于使用OO表示赞同，觉得是好方法。但是却没有使用。

      2008年4月13号补充：需求调研一个阶段告一段落，回到北京准备考试。在火车上一直跟同学讲领域驱动开发，讲我过去做的两个使用OO开发的项目的感受，并对比之前使用面向过程方法做项目的感觉：

      1 领域驱动设计，越是复杂、变化灵活的项目越要采用贴近领域的对象模型，只有小的项目才可以尽可能简化对象使得测试刚好通过即可。

      2 切忌UI驱动设计。我做的视频监控项目从最初的需求里包含GUI，到后来不要UI，真是惊天动地的大变化。另外一个作业管理的界面我们修改了20多版，而业务还是那点儿业务。UI可以辅助挖掘需求，但是把它作为最后一件事完全可以。

      3 切忌数据库驱动设计。关系数据库以数学为基础，距离现实领域太远，过早陷入其中危害无穷。

      4 面向对象是比面向数据、面向过程更加先进的方法。我说，当做那个作业管理子系统时，我将函数拆分的非常细，每个函数都是单一职责的，但是管理起来很费劲。我举例说，比如你有一堆帮助文档，包含了J2EE的方方面面，为了方便查找，我想你可能会按照主题将他们放在不同的文件里，然后再放到不同的文件夹里。那么这些文件就是类，文件夹就是包。虽然面向过程编程，你可以采用良好的命名规范，并将其放入单独的文件里（比如Delphi的unit，VB的module），但是其封装性和复用性明显要弱于OO。也就是这种最佳实践再向前迈一步就是OO了。

      5 我的感觉是，越是大型、复杂的商业应用越适合采用OO。虽然OO不完美，OO不是银弹，OO也没有REST、SSOA等时髦，也许话题很陈旧，很“入门”，但是，OO在国内应用的现状，就足以反映出，这是个值得探讨的问题。

[Evans03]Eric Evans，2003，领域驱动设计：软件核心复杂性解决之道。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

项目组内部推荐书目

零雨其蒙

2008年2月

前言

本文介绍理解本项目所有架构、设计思想和具体技术、工具使用的著作，阅读以下著作，可以更好的理解我们的项目为何如此架构，为什么要使用这些工具，以及过去在项目中出现的文档中所简单描述的内容的背后原理是什么。

学会使用工具是很容易的，但是知道为何要使用这些工具以及如何进行企业信息系统的设计是非常困难的。因此，阅读书籍首先要明确自己的学习目标，然后按照本文的分类去阅读将比较容易而不至于被如此之多的知识淹没。

比如你可以先学会使用Eclipse，SSH框架开发一个小的只包含CRUD操作的网站Demo，然后再去理解SSH是如何解决企业应用中必须要解决的问题的，阅读Fowler的《企业应用架构模式》是最好的起点，了解哪些问题是企业应用必需要解决的问题，并发处理是大型企业应用必然会遇到而在开发桌面应用程序不会遇到的，而且也是在单元测试阶段最不容易发现问题的。因此仔细阅读这一部分是非常必要的，包括线程的并发访问，数据库并发访问使用数据库事务（数据库提供了怎样的隔离机制和锁机制，如何设置隔离级别，以达到效率和安全的平衡）和业务事务（J2EE环境下如何使用两阶段提交来解决这一问题和对于长事务使用离线锁模式。

同时你可以通过编写这个Demo对于Java有个认识，并与已经学习过的语言建立联系。

但必须要明确学习目标，做Demo就是为了学会使用SSH和Java，而非为了掌握设计和架构思想。

本文所推荐的书籍就是目前项目使用的架构和开发方法论的参考书籍，因此如果想要全面理解项目使用的架构、技术和开发方法论，做到知其然并知其所以然必须认真阅读以下图书，这是一个最简集，当然很多思想还来自于其他书籍和实践经验。

PS：我花了一年时间阅读这些书籍，某些图书在我的Blog上有读书笔记，大家可以参考我的读书笔记阅读原著，因为毕竟我们有相似的经历，我想我当时遇到的困惑也可能是大家会遇到的困惑。

Blog：www.blogjava.net/sslaowan

软件开发综述类

   建议首先阅读本分类中的图书，以对项目整个使用的方法的全貌有个总体了解。

   对于软件开发过程的综述，包括对于UML，模式，面向对象，迭代方法，敏捷UP的讨论，Martin Fowler在多部著作中推荐了Larman的《UML和模式应用（第三版）》，其中介绍了完整的从需求分析（用例，补充说明书，SSD，操作契约），领域建模，到面向对象设计（RDD，GRASP，GoF设计模式）的敏捷的迭代过程，其中也讲解了各种实战中的UML的画法。另外一本Ambler的《Object Primer》，也是讲述敏捷语境下的面向对象技术，其风格更加严肃，不过对于业务规则，用户界面，持久化等的讨论可以作为Larman的著作的补充。

需求分析类

     建议首先阅读Larman的著作，以便了解需求分析并不只是依靠用例，然后编写用例的必读书目是Cockburn的《编写有效用例》，之后可阅读《有效用例模式》。

     还有一本讲述业务规则的图书对于理解业务流程等概念很有帮助，如果你像我一样想明确区分业务流程，工作流，领域逻辑，业务逻辑等概念，因为这对于如何组织系统架构的分层具有重大意义。

面向对象分析

建议阅读Martin Fowler的《分析模式：可复用对象模型》，里面关于库存和财务，交易，计划，组织结构模式，测量，观察模式的讨论，对于为我们的项目建模有一定指导作用。

另外Eric Evans的《领域驱动设计：软件核心复杂性解决之道》也是一本好书，其对于实体，值对象和服务的讨论对于理解项目架构思想很有帮助。

面向对象设计

建议阅读Robert Martin的《敏捷软件开发：原则，模式和实践》，其Java/C++版，和C#版同样具有帮助，其中对于OCP，DIP，SRP等OOD原则的讨论非常深入透彻，对于GOF设计模式的讲解和其他相关模式的摄入都对于理解什么是面向对象设计，以及怎样的设计才是正确的非常有帮助。

对于如何发现对象和为对象分配职责这一问题，除了阅读Larman和Ambler的书之外，Wirfs-Brock编写的《对象设计：角色，责任和协作》是对这一问题的深入讨论，其中的诸多方法如角色构造型，和对于责任，角色，协作的充分讨论，对于帮助找到解决之道很有帮助。

J2EE架构

对于信息系统架构和设计的权威著作是Martin Fowler的《企业应用架构模式》，它可以帮助你理解你所熟悉的和不熟悉的架构、设计决策背后隐藏的原理。其对于分层架构，领域建模，并发控制（线程和事务，锁机制），数据持久化策略（包括数据访问接口，实体关系映射等）等的讨论都很清晰，对于理解项目中的分层结构，建立领域模型，O/R映射及其他架构模式的运用的动机有更为深入的理解。配合《POJO In Action》（该书是建立在Fowler的《企业应用架构模式》，Evans的《领域驱动设计》和Johnson的《J2EE without EJB》等著作的基础上写的，你可以自己决定阅读顺序），有助于了解在敏捷J2EE架构下如何应用这些模式，其中使用了Spring，Hibernate框架，与我们的项目最为接近。

     建议阅读《J2EE核心模式》，本书是Sun公司编写的，描述了实战中的J2EE项目使用的模式，项目中使用的很多模式来自于该书，虽然最有用的部分在Fowler的书中已经有阐述，但是直接在J2EE语境下进行讨论还是有必要的，然而《POJO in Action》的出现，多少对此削弱了一些。

     Struts+Spring+Hibernate的入门快速上手书籍可参看郭峰的《Spring从入门到精通》。 主要阅读控制反转和依赖注入，声明式事务处理，持久化处理（使用JdbcTemplate和整合Hibernate）。其他类似书籍所讲内容大抵相同，所以建议参看其中一本快速入门，更深入的讨论请阅读Johnson的《Spring高级编程指南》。

     Spring方面的书籍最好按顺序阅读Rod Johnson（他是Spring之父）的三部巨著《J2EE设计开发编程指南》《J2EE without EJB》和《Spring高级编程指南》，对于全面理解Spring的使用动机，设计原理和最佳实践会有一个深入的理解。其中充分讨论了企业应用应该注意的问题，J2EE经典架构的问题，应该如何对待EJB，以及更好的替代EJB的方案是什么，为什么他们是更好的。这对于理解项目中为什么使用这些技术作了最为深刻的讲解。而Spring的开发手册可作为一个速查的手册（主要阅读依赖注入，声明式事务处理，持久化，安全，远程访问等章节）。实践中的Spring请参阅《POJO in Action》等图书。

     Hibernate的权威之作无疑是《Hibernate in Action》，是Hibernate之父写的，里面充分的讲解了持久化的最佳实践，不过没有中文版，其缩略版是Hibernate开发手册，可以看这个作为速查，关于事务，持久化，锁等可以参阅Fowler和Johnson的书，也可以参看《POJO in Action》。

     关于Struts，建议阅读《Struts in Action》。

     项目中用到的其他技术还包括：RCP客户端，其中主要使用的Eclipse核心架构，在这里推荐阅读Kent Beck和Gamma写的《Contribute to Eclipse》，Gamma是Eclipse的首席架构师，本书详细的讲解了Eclipse架构中所用的设计模式和设计思想，对于插件架构的讲解对于我们编写RCP客户端大有帮助。没有任何一本Eclipse的书籍可以代替本书的价值。阅读本书的意义在于帮助你设计客户端程序，而关于一些基本的知识（如JFace，SWT）请参考RCP编写的专门书籍（中国人写的目前好像只有一本），另外也可参考《Agile Java》。

jBPM工作流引擎请参阅Spring对于jBPM的扩展项目的文档，只有英文版。当然还要阅读jBPM的官方文档。一些通俗的例子请参见项目组内部文档。另外阅读Fowler的《企业应用架构模式》和一些工作流、业务流程管理的书籍对于理解工作流引擎大有裨益。

对于J2EE安全管理部分可阅读Johnson的《Spring高级编程指南》。手把手入门教材是罗时飞编著的《敏捷Acegi、CAS－构建安全的Java系统》和Acegi的官方文档。而在实际项目中的安全管理和Acegi的使用请参考JavaEye（www.javaeye.com）的一些讨论和文章。

Java与J2EE

    推荐阅读《Agile Java》，其采用测试驱动开发的方式讲解Java的基础知识，是目前我所见过的最能读下去的Java图书。作为速查可以找一本计算机二级复习用书。最为权威的著作是《Core Java2》，不过更象是API手册。最为深邃的图书是《Thinking in Java》和《Effective Java》，对于Java有深入了解可以仔细看看。

     另外找一本专业的J2EE图书，里面会详细讲解JSP，Servlet，JNDI，JDBC之类的原理和用法，建议选用和IBM Webshpere或BEA Weblogic无关的J2EE图书和有关的J2EE图书各一本。

数据库

建议至少阅读《Oracle DBA入门手册》，真正理解Oracle的优化配置，SQL语句的正确写法，序列，索引，触发器，函数，数据库模式设计以及并发处理等主题。

Unix

    建议阅读一本AIX的专著，以理解Unix操作系统的基本原理和使用方法。

敏捷开发

关于极限编程，推荐阅读Kent Beck（他是极限编程的创始人）写的《解析极限编程：拥抱变化（第2版）》，以帮助你理解我们项目所采用的结对编程，测试驱动开发，重构，用户故事等实践及其背后的原理。对于如何在敏捷环境下做计划，本书的讨论应该在加上Kent和Fowler合著的《规划极限编程》才更完整。制定计划是非常重要的，同样控制过程，检验计划完成情况更加重要。

对于敏捷开发更全面的理解来自于Jim Highsmith的《敏捷软件开发生态环境》，其中讨论了极限编程，ASD，FDD，DSDM等敏捷方法。

关于为何不使用瀑布模型而使用迭代方法请参看Larman的《UML和模式应用》，Fowler的New Methodology，McConnell的《代码大全》。其中Larman和McConnell都在书中引入了大量实验数据来说明这一问题。瀑布模型在国际上公认出自于Winston W.Royce博士于1972年发表的论文《Managing the Development of Large Software Systems》，但是该论文实际上是反对瀑布模型的。

在项目中会使用一些极限编程实践工具，如重构，JUnit，Ant等，请参考阅读以下书籍：

关于重构的最权威的讨论来自Martin Fowler的《重构：改善既有代码的设计》，Eclipse中的重构功能中使用的重构名即出自此书，其对于代码坏味道的总结对于避免团队成员写出糟糕的代码有很好的指导作用；而其对于重构方法的讨论非常细致，步骤很清晰，幸运的是工具已经代替你做这些容易出错而又细致的步骤，你只需要理解在何种情况应该使用什么重构法即可。

关于JUnit的最好且最简单的著作是《JUnit in Action》，项目中组织测试的经验即来自本书。由于项目采用J2EE和测试驱动开发，因此本书是必读书籍。

关于Ant的最全面的讨论是《使用Ant进行Java开发》。其中对于持续集成的讨论对于实践这一理论很有帮助，然而对于持续集成更全面的讨论来自于Fowler的文章Continuous Integration。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

2008-1-29

1.1.1   关系的映射

对象和关系处理连接的方式不同，会造成两大问题：

1、表现方法不同：

a、对象是通过在运行时（内存管理环境或内存地址）中保存引用的方式来处理连接；

   public class A{

      private B b;

}

 A和B的连接，通过在A的实例a中保存的B的实例b建立。

b、关系数据库则通过创建到另外一个表的键值来处理连接。

 表A中保存表B的ID，作为A的外键，来建立A和B的连接。

2、对象可以很容易的通过集合来表示多个引用。

   规范化则要求所有的关系连接都必须是单值。

解决办法：通过对象中的一个标识域来保持每个对象的关系特性，并且通过查找这些值来保持对象引用和关系键之间的互相映射。

1.1.2   继承

三种模式：单表继承，具体表继承，类表继承。

Fowler倾向于使用单表继承：因为易于实现和重构。

1.1.3   建立映射

Fowler建议：首先使用领域建模，然后在不超过六个月的迭代中建立数据库模型。

如果领域设计和数据库表同构有意义，则考虑使用活动记录代替。（原文：If a database design isomorphic to the Domain Model (116) makes sense, you might consider an Active Record (160) instead.）

2        Web表现层

MVC中M是指领域模型。

2.1    输入控制器模式

MVC中的控制器：

一种理解为“输入控制器”，主要作用为：

1、从请求消息流中读取数据

2、将业务逻辑传递给一个合适的领域对象

3、将返回的数据放到HTTP会话（Session）对象中，与视图共享。

第二种理解为“应用控制器”，主要作用为：

处理应用程序流，决定视图应该按什么顺序出现。

Fowler对输入控制器的结论，更为准确地说法是为每个动作准备一个页面控制器（Page Controller）。

2.2    视图模式

A two-stage view (Figure 4.3) breaks this process into two stages, producing a logical screen from the domain data and then rendering it in HTML. There's one first-stage view for each screen but only one second-stage view for the whole application.

3       并发

并发造成的问题：

1、更新丢失。A读取了一张表中的数据，然后对其修改。这时B也读取了该表中的数据，修改后将其保存。这时A才修改完，将其保存。这样A就覆盖了B的修改。

2、不一致读。

并发涉及到两个层面：

1、客户端访问应用服务器，使用线程或进程，一个进程中可包含多个线程，线程使用共享内存，这样就会造成并发问题。

2、访问数据库，这会涉及到事务，并发访问数据库。

系统事务：发生在应用程序到数据库之间

业务事务：发生在用户到应用程序之间

解决并发的两种方式：

1、隔离

2、不变性

预防死锁！

2008-1-30

3.1    事务

在企业应用中处理并发最主要的工具是事务。

事务：1、事务是一个有边界的工作序列，开始和结束都有明确定义

      2、所有相关资源在事务开始和结束时都保持一致。

      3、每个事务都必须保证要么全部完成，要么什么都不做。

ACID：

原子性：

一致性：在事务开始和完成的时候，系统地资源都必须处于一致的，没有被破坏的状态。比如一个人买啤酒，虽然少了钱，但是得到了等价值的啤酒，其拥有的总资产不变。

隔离性：一个事务，直到它被成功提交之后，它的结果对于任何其他的事务才是可见的。

持久性：一个已提交的事务的任何结果都必须是永久性的，即“在任何系统崩溃的情况下都能保存下来”。

事务资源：在技术讨论时，使用事务资源表示进行事务处理的任何事物——即使用事务来控制并发过程。

长事务：跨越多个请求的事务叫长事务

几种不一致读的情况：

脏读：脏读是指事务A访问并修改了一个数据，但还没有提交回表中，这时事务B访问并使用了该数据，则事务B读到的可能就是一个“脏”的数据。依据脏数据所作的操作就很可能是错误的。

不可重复读：不可重复读是指事务A对某数据进行一次读取后，数据被事务B访问并修改。当事务A再一次访问数据时，会发现跟前一次读到的数据不一致。

幻读：幻读是指当事务不是独立执行时发生的一种现象。例如事务A对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，事务B也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，操作事务A的用户就会发现表中还有未修改的数据行，就好象发生了幻觉一样。

不可重复读的重点是修改:
同样的条件,你读取过的数据,再次读取出来发现值不一样了
幻读的重点在于新增或者删除
同样的条件,第1次和第2次读出来的记录数不一样

几个隔离级别：

读未提交：意思就是说，允许用户读取其他用户未提交的事务中修改的数据。比如B修改了数据D（比如从2改成了1，此时D被修改了，成了脏数据），但是还没有提交，在这种隔离级别下，数据库允许此时A读取数据D（即允许脏读），读完显示给A后，B做修改的事务回滚了，也就是修改实际上没有完成，那么A读到的数据D（值为1）就不是真实的情况（应该还是为2）。这时A对数据D进行操作，就可能出现错误，比如将D（商品价格）*0.8（折扣）然后保存到另一张表（比如是用户订单）中，那么就保存了一个错误的结果。

读已提交：意思就是说，数据库允许用户读取其他用户已经提交的事务中修改的数据。允许不可重复读这种不一致的情况发生。这样允许事务A未提交时，事务B对A已读到的数据进行修改。但是事务A读到的数据一定是已经提交的数据（因此不可能出现脏读），而在读未提交隔离级别下，可以读未提交的数据。

可重复读：锁定查询中使用的所有数据以防止修改（避免脏读和不可重复读），但是不防止插入数据，这时重新读取时，就会读到之前没读到的数据，出现了幻读。此隔离级别允许出现幻读。Fowler：这种幻读出现在你向一个集合添加一部分元素而读的人只能读到其中一部分的时候。

可序列化：实际上是独占方式读取数据。

隔离级别与所允许的不一致读：

2008-1-31

3.2    离线并发控制的模式

处理业务事务的模式

乐观离线锁

悲观离线锁

3.3    应用服务器并发

应用服务器自身的进程并发，这里不涉及事务。

最简单的处理办法是使用每会话一进程，就是每个会话都在自己的进程中运行。问题是：大量资源的耗费，因为进程是昂贵的。可以通过进程池来提高利用率，这时每个进程在一个时刻只处理单个请求，但可以在时间序列上处理来自不同会话的多个请求。问题是：必须保证每个请求结束时都释放其占用的所有资源。

每会话一线程，即在一个进程中运行多个线程来进一步提高吞吐率。每次请求由进程中的某个线程处理。

4       会话状态

Fowler建议：

1、倾向于使用服务器会话状态模式，特别是在以下情况下：

   a、备忘文件被远程存储以备系统在服务器崩溃之后仍能恢复

2、使用会话状态模式来存放会话标识号和数据量较小的会话。

3、我个人并不喜欢数据库会话状态模式，建议只在以下三种情况使用

a、需要故障恢复和集群时

b、无法存储远程备忘文件时

c、不关心会话间数据隔离时

5       分布策略

分布式对象第一定律：不要分布使用对象。（大多数情况下使用集群）

2008-2-1

6       通盘考虑

Core J2EE分层模型

Marinescu分层模型

服务层将工作流逻辑从纯粹领域逻辑中剥离出来。服务层所包含的逻辑一般都特定于某个用例，并与其他一些基础设施相互通信。（Fowler个人认为这种分离偶尔有用，但一般情况下没用）

Mircosoft DNA分层模型

DNA中的记录集实际上充当一种各层的数据传输对象（DTO）。业务层能够根据自己的方式修改记录集，�