博客园_Teddy's Knowledge Base

讨论：WCF可序列化的ActiveRecord实现有意义吗？

2010-08-08T06:37:00Z

本文的目的，是探讨WCF可序列化的ActiveRecord实现是否有意义。

ActiveRecord模式简介

ActiveRecord模式是Martin Fowler的企业应用架构模式中提到的一种数据访问模式，如下图：

Person类包含lastName, firstName等这些属性，一个Person类的实例，对应数据库的一个Person表或视图的一条记录，每一个属性，对应数据库记录的一个字段；同时，Person类包含CRUD方法，封装了对数据库的操作；Person类同时还可以包含其他和这条记录相关的业务方法。

ActiveRecord模式和Repository模式，从外部接口上看起来在很多方面很像，但理念其实有区别：

ActiveRecord和数据库访问紧耦合，它更像是对数据库中的一条记录的包装类；Repository则隔离了具体的数据访问和领域对象的CRUD的耦合，这样一层隔离的存在，使得Repository更灵活，他可以还是像ActiveRecord一样包装一条数据库记录，却不限于数据库，数据也可以保存在任何地方，只要外部接口不变，其内部实现有更灵活性。
ActiveRecord的属性，一般应该完全对应于数据库的字段；而Repository的属性，则没有这样的限制。
ActiveRecord对数据库访问的紧耦合，也不完全是缺点，紧耦合的好处是，ActiveRecord上的方法的参数，也可以是和数据库紧耦合的，例如：它的CRUD方法的参数，可以包含数据库特定的信息，如字段信息，或者数据库特有的查询条件，面向数据库的查询条件，从数据库的视角当然更直观；而Repository在外部接口上，原则上是不能有任何数据库特定的信息的，如果最终还是要查数据库，还需要额外把非数据库特定的查询条件转换为数据库特定的查询条件，对于参数复杂的查询，处理查询条件的成本要高得多。

什么是WCF可序列化的ActiveRecord？

这里的“WCF可序列化”指的是，一个类可以被支持WCF DataContract序列化的类进行序列化。这里，“WCF可序列化的ActiveRecord”指的是，不仅仅ActiveRecord可序列化，还包括服务于ActiveRecord的查询条件也可以被序列化。ActiveRecord及其查询条件可以被WCF序列化就意味着，他们可以通过WCF服务进行远程通信，换句话说，他们可以作为DTO对象。

在有关ActiveRecord的讨论中，经常会被提到，ActiveRecord不能用作DTO，因为其内部包装着数据库访问，尤其不能跨进程边界传递ActiveRecord实例。这种说法当然没错，不过他有一个前提，就是如果ActiveRecord实例连接着数据库，通过ActiveRecord上的CRUD可以直接访问数据库的话。换句话说，如果可以解除ActiveRecord实例对数据库的连接（例如：可以提供Attach(db)/Detach()方法将一个ActiveRecord实例绑定或解绑具体的数据库连接），那么，把它作为DTO我觉得未尝不可。

让数据库查询条件作为DTO会不会有问题呢？在传统的程序开发中，一般我们说传递“数据库查询条件”往往指的是传递SQL片段，虽然传递SQL使得查询条件非常灵活，却毫无疑问是不安全的。但是，如果是对SQL语义的查询条件进行强类型的包装，则可以做到没有这样的安全隐患，却又可以保留查询条件灵活的特性。

如果从安全性的角度，能够接受ActiveRecord及包含数据库查询语义的强类型的ActiveRecord的查询条件作为WCF服务的DTO进行传递，那么，我们就可以再来谈谈由此带来的好处了。以下，假设我们可以用一个强类型的Criteria对象来表示一个任意的数据库语义的查询条件，并且它可序列化，可以作为DTO进行传递。

简化CRUD和WCF服务接口。相对于Repository只能使用一个或多个非数据库语义的参数来描述查询条件，如果我们可以用一个Criteria对象来表示一个任意的数据库语义的查询条件，我们就只需要一个Find(Criteria criteria)方法，作为所有的查询条件的入口。则无论对于CRUD本身的API还是WCF服务的API，都得到了极大的简化，而描述能力却大大提升。
简化数据库查询语句的构造和执行。在数据层的数据库查询的执行端。由于我们的Criteria是基于数据库语义的强类型封装，翻译成SQL的成本，相对于Repository只能使用一个或多个非数据库语义的参数来描述的查询条件到SQL的翻译，成本要低得多，语义上也直接得多。

需要注意的问题：

如何限制客户端的查询能力？由于采用这样一种方案的ActiveRecord使得客户端拥有了最大化的自定义查询能力，我们一定需要有一些机制，可以限制这种能力：在Find(Criteria criteria)的实现端，在执行查询之前，需要根据一定的规则，验证criteria是否允许执行；在客户端的查询对象上，我们也可以有一些限制，比如，只允许某些字段作为查询条件，或者，有些ActiveRecord是只读的，不允许写操作。
以数据库的思维来构造查询条件。即使在允许的查询条件范围之内，由于不同的查询组合条件潜在地会导致不同语义的数据库查询被执行，不同的语义可能会导致不同的性能差异，因此，在客户端构造查询条件的时候，更大程度上，我们需要以数据库的思维来构造，而不仅仅是以业务的思维。

有人可能要问，客户端代码需要以数据库的思维来写，或者可能影响到数据层的执行效率，这样的设计是合理的吗？我觉得要看情况。

首先，ActiveRecord是允许和数据库紧耦合的，从这个角度，ActiveRecord的客户端本身就是允许通过ActiveRecord的外部接口，接触到数据库特定语义的。从这个角度来说，给予客户端一定的构造查询条件的自由度，至少是说得过去的。

其次，所谓ActiveRecord的客户端，对于不同的项目来说，对性能的要求可能有很大差异。比如，如果是一个公司内部项目，客户端的并发，整体的数据量也不是很大，则更多关注的可能是灵活性，那么，可以给客户端尽可能多的自由度；而如果是一个开放的WCF服务，或者并发或数据量很大，那么，可能应该尽可能的减少客户端的灵活性，Find(Criteria criteria)这样过于灵活的接口，也可能是不合适。

欢迎讨论！

本文链接

理解Design Pattern

2010-08-02T12:23:00Z

本文的目的是以最精炼的语言，理解什么是Design Pattern，为什么需要Design Pattern，和关于Design Pattern的争论。

什么是Design Pattern？

从字面上理解，Pattern，指的是解决常见问题的可重用的方案。Design，则限定了，这里的Pattern是为软件的设计服务的。因此，所谓Design Pattern，指的是解决常见的软件设计问题的可重用的方案，或者说解决方案的模板。

两点需要特别注意的是：

算法不是Design Pattern。
Design Pattern是为Design服务的，而不是为具体的实现服务的。

说道什么是Design Pattern，不得不提起一本书：《Design Patterns: Elements of Reusable Object-Oriented Software》，俗称Gang of Four或者是GoF。为什么？因为这本书太有名了，有名到太多人从听说到自以为熟悉Design Pattern，都是通过它，甚至狭义地认为所谓Design Pattern，就是指的GoF中的23种Pattern。这真是一个相当大的误会了。同样的，很多人提到Design Pattern，必提到SOLID原则，其实也是误会，SOLID是面向对象设计的基本原则，并非Design Pattern的基本原则，只是因为GoF是面向对象的Design Pattern，所以GoF中的Pattern自然需要遵守面向对象的SOLID原则。

针对不同的软件开发领域，其实有许多前人总结的Pattern。例如：GoF其实属于典型的面向对象Design Pattern，是前人从面向对象的设计实践中，总结的一些典型的Pattern。另外，还有针对架构设计的Pattern，针对企业集成的Pattern，针对SOA的Pattern，等等。大大牛Martin Fowler维护了一个他个人感兴趣的不同开发领域的Deisng Pattern的Catalogs。

Pattern只是针对不同的场景的一些可重用的方案，因此，无需崇拜甚至神话任何已有的Pattern。一但一个Pattern服务的问题场景发生了变化，则往往可能导致这个Pattern不再适用此场景，或者需要被修正。任何人也都可以发现和总结新的Pattern。

为什么需要Design Pattern？

应用Design Pattern主要的好处如下：

降低设计成本 - 每一个Design Pattern是解决一个常见问题设计问题最佳实践，因此，对于相同的问题，我们就无需做重复的设计，只需要重用即可。
降低设计风险 - 相对于未经实现证明的朴素的设计，Design Pattern作为来源于实践，并且已经被前人证明的最佳实践，无疑风险更小。
降低讨论和交流的成本 - 对于软件设计专家之间对设计的交流，如果大家都理解同一个Design Pattern，则无需提供太多的设计细节，就能让对方理解一个设计，因此交流的成本大大降低。

关于Design Pattern的争论

Design Pattern是否影响性能？

一定程度上，可以说“是”。相对于直接、朴素的实现，Design Pattern为了获得一定的灵活性，往往会引入一些额外的层次，对于局部来说，客观上的确是占用更多的资源，或者影响一些性能。

但是，我们不能孤立的看问题。撇开那些有极至性能要求的应用，Design Pattern在局部引入的一点点性能损失，往往并非是不可接受的，且还要考虑到其带来的其他好处；而一个错误的或者不够灵活的设计更有可能造成程序整体的缺陷和瓶颈，并且往往补救的成本要高得多。

Design Pattern是否为了弥补具体语言描述能力的不足？

判断这个命题，要看这里的“Design Pattern”是泛指，还是特指。如果是特指，Design Pattern既然只是指一些可重用的方案模板，针对，一些本身就是来源于特定语言的编程实践来说，当然，未尝不能使这个命题成立。例如：Core J2EE Patterns。

但是，对于更多的并非来源于具体语言的的Design Pattern，如GoF这样的面向对象设计的Design Pattern，它关注的是面向对象设计的基本原则和限制，和具体的语言没有任何关系，又何来“弥补具体语言描述能力的不足”之说呢？

本文链接

理解O/R Mapping

2010-07-31T16:22:00Z

本文的目的是以最精炼的语言，理解什么是O/R Mapping，为什么要O/R Mapping，和如何进行O/R Mapping。

什么是O/R Mapping？

广义上，ORM指的是面向对象的对象模型和关系型数据库的数据结构之间的相互转换。

狭义上，ORM可以被认为是，基于关系型数据库的数据存储，实现一个虚拟的面向对象的数据访问接口。理想情况下，基于这样一个面向对象的接口，持久化一个OO对象应该不需要要了解任何关系型数据库存储数据的实现细节。

为什么需要O/R Mapping？

广义上，因为我们需要面向对象来描述我们的业务，我们也需要关系型数据库来存储我们的数据。

有人可能会提到，我们未必要用面向对象来描述业务，或者未必用关系型数据库来存储数据。没错，但是，至少，还是有相当大部分的程序，同时需要这两者的合作。存在即合理。因为同时需要彼此，两者都客观存在，就值得讨论。

既然从广义上，存在即合理，无需讨论为什么需要ORM，很多关于ORM的讨论，其实都是针对上面提到的狭义的定义。但是即使到目前为止，真正能够完美的实现这个狭义定义的ORM的工具，其实还并不存在(很多工具如Hibernate，已经相当接近，但是，离完美还有相当距离)。

既然还不存在，那么，在讨论需不需要之前，我们恐怕要先讨论一下，是否可能，即从理论上，从数学上，面向对象的对象模型和关系型数据库的数据结构之间，到底能不能做到完美的映射？要回答这个问题，我们要解决两个难题。

O/R阻抗失衡

第一个难题，叫“O/R阻抗失衡(O/R Impedance Mismatch)”，指的是OO对象模型和关系型数据库的数据结构之间的，设计理念上的差异。OO的设计理念，是以最正确的语义来描述真实世界；而关系型数据库的设计理念，则是从数学的角度，如何更有效的存储和管理数据。由于两者设计理念的差异，导致它们尽管从数据结构上，可能很相近，但是关注点往往是不同的。

例如：

从OO的角度，凡是语义明确，每一个对象语义上的属性，就应该定义为一个属性；从关系型数据库的角度，有可能考虑到一些属性从来不会被作为查询条件，而把多个语义上的属性，以一定的格式，存在一个数据表的字段中，也有可能因为一组语义上的属性使用的频度完全不同与另一组属性，即使他们语义上属于一个对象，也有可能将他们拆分成两个数据表来存储。
从OO的角度，对象只关心自己的固有属性，不需要被唯一标识；但是，从关系型数据库的角度，一般一个数据表中的每一行数据都需要要一个唯一标识，且很可能是语义上没有意义的，如自增长的标识。
从OO角度的优化，一般遵循SOLID这样的原则，以更正确的语义来组织对象；从关系型数据库角度的优化，往往为了查询性能，来修改字段的类型、长度，修改索引，甚至分表、分库。
...

一个ORM工具想要通过简单的配置，完美的解决“O/R阻抗失衡”问题，在我看来几乎是不可能的。但是，一定程度上，通过灵活的配置支持绝大多数常见的映射策略，再加上提供可供用户通过自定代码来扩展的接口的话，应该还是可以相当接近完美的。

文化阻抗失衡

第二个难题，叫“文化阻抗失衡(Cultural Impedance Mismatch)”，指的是关系型数据专家和面向对象专家之间的文化差异。关于这个难题的最经典的争论是“到底应该以关系型数据库的数据结构来驱动，还是以OO的对象模型来驱动程序的开发？”。

关于这个争论，OO专家的主要观点是：
我的业务才是程序的核心，数据库只是为我持久化数据的需求服务的，所以设计OO对象模型的时候，我不应该考虑如何存储到关系型数据库的问题；

而数据库专家的主要观点是:
数据才是公司的核心财富，数据的稳定性远远强于OO对象模型的稳定性，由OO对像模型来驱动数据库架构的设计，根本保证不了性能，数据库维护的成本根本不可接受。

其实，争论的真正原因即在于“关系型数据专家和面向对象专家之间的文化差异”。大大牛Scott W. Ambler的文章Why Data Models Shouldn't Drive Object Models(And Vice Versa)，很好的解答了这个问题。

归根结底，既然OO和关系型数据库都是不可缺少的部分，需要协同工作，希望做到完美的ORM，不仅仅需要好的ORM工具，更需要无论是OO专家还是数据库专家互相了解对方的技术和设计理念。对一个OO专家，一个ORM工具，可以对其所支持的常见的映射，提供直接的支持，但是，应用这些ORM工具的OO专家，必须了解关系型数据库，知道如何在不影响OO对象的语义的前提下，如何设计一个更容易映射到关系型数据库的对象模型，知道如何选择ORM工具所支持的映射方式，以及如何用自定代码扩展ORM所不能方便支持的映射方式；同样的，对一个关系型数据库的专家，也需要了解OO的语义，和可能发生的重构，从而，使得所设计的数据库结构，更容易映射到OO对象，更容易响应OO对象模型的重构。如此才是真正的和谐，真正的完美。

小结

综上所述，无论对一个OO专家还是对一个关系型数据库专家，都需要了解OO，并了解关系型数据库，了解ORM的基本原理。离开全面的知识，一个再完美的ORM工具也无法被正确使用，拥有这些知识，则能够充分利用已有的ORM工具来加速自己的工作，并且合理的或扩展现有的ORM工具，或用自定代码，实现ORM工具能力之外的ORM映射。这才是理想的ORM实践。下一章节，我们就来谈谈一下，ORM的基本原理。

如何进行O/R Mapping？

简单映射

1. Class <-> Table

一个Class一般可以映射为一个Table，一个Class的实例对应Table的一行数据。但是，一个Table中的每行数据，一般都需要有一个主键来唯一标识这行数据，而一个Class的每个实例，则不一定需要一个唯一标识。

2. Property <-> Field

一个Class的Property一般可以直接映射为Table的一个Field。但是，他们的数据类型不一定直接匹配。如果他们代表的数据类型的语义上可转换，则Field的类型，应大于等于Property的数据类型。如果他们代表的类型语义上不可转换，则需要在应用程序层面，进行自定义的转换。

继承映射

1. 单表映射整个继承体系

用一张数据库表存储整个继承体系中的所有Class的数据，数据表需要额外的标志字段来区分一行记录应该映射到继承体系中的哪一个Class，适合继承体系层次较少，总记录数相对较少，子类对父类的属性扩展也相对不那么频繁的情形。

单表映射整个继承体系的优点是读/写继承体系中的每个Class的数据，都只需操作一张表，性能较好，并且，新增继承类，或扩展Class属性都只需要增减一张表的字段就可以了，易于维护；主要缺点是，因为继承体系中所有的Class共享一张表，表中会有比较多的NULL字段值的数据，浪费了一些存储空间，同时，如果记录数过多，表就会更庞大，也会影响表的读写性能。

2. 一个Class映射一个具体表

所谓一个Class映射一个具体表就是每个Class对应一张数据表，并且，每个数据表冗余包含其父类的所有属性字段，并且，子类和父类共享相同的主键值。一个Class一个具体表方案适合需要较高查询性能，继承体系层次不太复杂，并且基类包含较少的属性而子类扩展较多属性，并且能够承受一定的数据库冗余的情况。

一个Class映射一个具体表方案的优点主要就是查询性能好，读操作只需操作一张表，和实体数据的对应结构清晰，数据库表迁移和维护会比较方便；主要的缺点是数据冗余较大，因为每次插入一条子类数据时，同时要插入一份子类包含的父类字段的数据到所有父类层次表中。

3. 一个Class映射一个扩展表

所谓一个Class映射一个扩展表是指继承体系中的每个Class对应一张数据表，但是，每个子类不冗余包含父类的所有属性，而只是包含扩展的属性和共享的主键值。一个Class映射一个扩展表方案适合继承体系非常复杂，结构易变，并希望最大程度减少数据冗余的情形。

一个Class映射一个扩展表方案的优点是结构灵活，新增子类或插入中间的继承类都很方便，冗余数据最少；但是缺点是，无论读还是写操作都会涉及到子类和所有的父类。读操作时，必须自然链接查询所有的父类对应的数据表，而插入或更新数据时，也需要写所有的父类表。

4. 通用的表结构映射所有的Class

这种方案其实不仅支持用一张表存储一个继承体系，它甚至可以支持，用一张表存储任意数量的不同Class。它的原理是元数据驱动。这张表的每一行，包含一个类型的标识字段，一个表示Class的属性名称的字段和一个表示Class的属性值的字段。在运行时，通过唯一标识取出描述一个Class实例的所有Property的值，再根据Property的名称来映射。

关于各种继承映射的实例分析和详细的优劣比较，请参见：Scott W. Ambler的O/R Mapping In Detail。

关联映射

1. 一对一关联、一对多关联（包含一对一和一对多的自关联）

所谓一对一关联，实际上还可以分为三种情形，即0..1 - 1，1 – 1，1 – 0..1三种情形；而一对多关联则分为* - 1和1 - *。

以下三种方案中第1)种为最常用的映射方案，后面几种是在某些特殊情形下可参考的方案：

1) 最常用的方案为为需要其他对象引用的类对应的表增加一个到被引用对象对应表的外键即可，只不过，与表对应的实体类代码中，对于一对多情形下的“多”这一端，需定义成集合类型；
2) 在Hibernate称为“组件（Component）映射”，举例来说，假如Person类包含一个Address成员类型的属性，而Address由City，Street，ZipCode三个成员属性组成，假如Address除了与Person关联不被其他对象使用，则我们可以考虑只用一张数据表Person来持久化Person和Address这两张表，Person数据表包含Person类中除Address的属性和Address类中的所有属性的集合，当然，这时需要在元数据中特别指明映射关系；
3) 还有一种针对上面的方案中的Person，Address两个类的持久化方案则是将Address类型的所有属性先序列化，再存入Person表的字段Address中，这样也可以只用一张表来持久化两个类，当然，本方案中这种被序列化对象成员数据量应尽量小；
4) 还有一种方案是共享同一主键值的一对一关联。即将原本可以同属于一个表中相对使用不太频繁的字段提出来放在另一张表中，这样，这两张表的记录就可以通过一个相同的主键进行关联。

2. 多对多关联（包含多对多的自关联）

所谓多对多关联自然就是* - *这种情形了。一般都需要一张包含关联双方主键的关联表，在取数据时，需要链接该关联表和数据表。

英文资料

本文链接

理解单元测试(Unit Testing)

2010-07-31T07:49:00Z

本文的目的是以最精炼的语言，正解什么是单元测试，为什么要单元测试，和如何进行单元测试。

什么是单元测试(Unit Testing)？

测试(Testing)这个词很容易理解，那么什么是单元(Unit)呢？一个单元指的是应用程序中可测试的最小的一组源代码。一组源代码可测试，一般要求其有明确的输入和输出。因此，一般来讲，源代码中包含明确的输入和输出的每一个方法被认为是一个可测试的单元。注意，这里指的输出，并不局限于方法的返回值或对输入参数的改变，而包括了方法的执行过程中，改变的任何数据。

为什么要做单元测试？

单元测试的目的，是将应用程序的所有源代码，隔离成最小的可测试的单元，保证每个单元的正确性。理想情况下，如果每个单元都能保证正确，就能保证应用程序整体相当程度的正确性。

另一方面，单元测试也是一种特殊类型的文档，相对于书面的文档，测试脚本本身往往就是对被测试代码的实际的使用代码，对于帮助开发人员理解被测试单元的使用是相当有帮助的。

如何进行单元测试？

隔离

要进行单元测试，首先就是要将被测试的单元，与所有外部依赖进行隔离。一般来讲，进行隔离主要有两种可选的技术，一种叫Stub，一种叫Mock。对于两个的区别和取舍，Martin Fowler有一个很经典的文章：Mocks Aren't Stubs。简单来说，如果要Stub或Mock一个方法，Stub指的是，为了测试，手动写一个相同签名的方法，根据我的测试需要，对给定的输入参数，返回一定的输出；而Mock则借助一定的框架组件，自动生成一个方法的实现，对于给定的输入，返回一定的输出。当然，所谓的Stub或Mock，并不单指对方法，尤其是在面向对象编程中，也可以是对属性，对对象或者对接口，等等。

为了方便实现隔离，对软件设计和开发的一个潜在的激励是，软件模块的设计人员和开发人员，不得不时时思考，在当前语言支持的各种特性的条件下，如何使得所写的代码，能够被方便的被隔离。虽然这看起来很像是一种限制，但是和软件设计的SOLID原则，其实是不谋而合的，因此，也就未尝不是一个优点了。

测试

解决了隔离的问题，我们就可以关注对一个单元的测试本身了。首先要提的一点是，所谓测试一个单元，一般往往是写一段测试脚本，给定输入，验证输出。但是，其实并非所有的单元测试都可以完全由计算机方便地自动完成的。尤其是如图形UI这样的比较抽象元素的判断。因此，从相对广义的角度来说，凡是能够用于验证一个被测试的单元正确性的所有方法进行的测试，都可以被认为是有效的测试。

自动化

解决了隔离和测试本身的问题，下一个需要讨论的就是测试的效率的问题。尽管上面提到了，所谓单元测试，不完全都可以由计算机方便地自动完成，但是，对于那些可以由计算机自动完成的单元测试，如何提高写测试代码和运行测试的效率呢？答案是，陆续出现了很多的测试框架和测试工具。这些测试框架或工具，一般都会提供提高创建测试脚本效率的工具，并且，提供自动化执行测试和查看执行结果的功能，往往还可以很方便的和代码的自动化编译和部署进行集成，使测试自动化。

Guidelines

这里整理了一些如何写好测试代码的Guidelines：

有测试总比没测试好
测试尽可能的小而快
使测试自动化
进行代码覆盖检测
在写任何新的实现代码或测试代码之前，先修复所有运行失败的测试
再简单的代码也需要测试
特别注意输入参数的边界案例
不要只测试正常流程，还要测试可选和例外流程
对于每一个报告的Bug，写一个对应的测试用例，方便回归测试
时刻注意，所有测试都通过，不代表程序就真的100%没问题，测试永远只是辅助

英文资料

本文链接

理解TDD

2010-07-29T17:24:00Z

本文的目的是以最精炼的语言，正解什么是TDD，为什么要TDD，和TDD的难点。

什么是TDD？

简单的说，TDD = 测试先行(TFD, Test First Development) + 重构(Refactoring) + 回归测试(Regression Test)。

如果要实现某个功能，TDD要求在初步定义完这个功能的外部接口之后，先根据这个功能的用例写测试代码(黑盒测试)，测试代码检验的是这个功能的外部接口的使用场景，而非具体的实现细节。然后，才是实现这个功能的这些外部接口，在实现的过程中，同时还会根据需要写一些单元测试，一般单元测试测试的不仅仅是外部接口，还包括实现的内部细节(白盒测试)。关于单元测试的更多讨论，请参考：UnitTesting。如果发现这些外部接口设计得有问题，则需要进行修改和重构。每次代码修改之后，或者增加新功能之前，都需要回归运行已有的所有测试(不仅仅是测试先行的这些测试，还包括所有的单元测试)。

测试先行保证了功能的所有使用场景的逻辑性和完备性；重构则在保证功能语义的前提下，尽可能安全的改进设计和实现；回归测试则保证了任何修改不破坏任何已有的功能，这样开发人员就能放心大胆地专注于实现或改进眼前的功能。这样无疑既提高了开发人员的信心和工作效率，而且时刻保证了功能的完整性和代码的正确性。

如果对TDD详细的前世今生感兴趣，请参考：TDD on WikiPedia

为什么TDD？

TDD最大的好处是时刻确保了每次添加或修改任何代码的过程中，对任何已有的功能都是安全的。尤其是对于编译和回归测试的运行时间较短的情况下，有大牛甚至建议每新增或修改超过10行可运行的代码，就运行一次回归测试。这样不仅仅能确保你写的每一行代码的正确性，而且，基本可以避免使用单步调试来发现问题，因为，问题往往就应该在最新的这10多条代码上。

TDD的另一个好处是，相对于几十页上百页的天知道和什么年代的代码同步的技术文档来说，TDD的测试代码因为描述的就是功能的实际使用场景，并且和代码一定是实时同步的，对开发人员来说，它其实是一种既准确，又易于理解，易于维护的“技术文档”。

TDD的难点

并非所有类型的代码都适合TDD，尤其是那些不能由机器简单的判断对错的情形，比如图形UI和数据库设计。
TDD需要让管理层意识到TDD的价值，为TDD预留额外的开发时间，并且强制每个开发人员按TDD的流程来写代码，需要自上而下的管理和开发流程的支持。

英文资料

本文链接

讨论: TDD in HTML & JavaScript 之可行性和最佳实践

2010-07-11T14:23:00Z

题外话

昨天就想发起这个话题的讨论，只是觉得对于讨论的支持，博客园现有的功能天然似乎还不能很好的支持。所以有了突然发现想在博客园发起一个有价值的讨论其实很难一文。亚历山大同志提到“博客园的讨论需要发起争议性话题，比如 .net sucks之类”。回顾如关于近期C#大论战的回应这样的近期引起讨论的焦点话题，貌似确实如此。深以为叹。近期的C#大论战是幸运的，尽管中间还是参杂了很多口水，李建忠老师的加入，一定程度上最终将话题引向了正确的方向。幸哉。我这个围观群众也从中获益良多。不仅仅是对于这个技术话题正确理解，还包括李老师在他的博客最后提到的：抛掉“非要辩个胜负，分个高低”的怪诞氛围，而是来一些扎扎实实的技术说理过程，相信会更有意义——如是，则国内技术社区成长可待。

言归正传，还是尽快开始我想讨论的主题，且不管讨论最终成效如何，既然发起讨论，还是先尽可能分享自己的想法，以示诚意。

TDD的背景

自从03年Beck正式提出（事实上在00年，Beck提出eXtreme Programming时，就已经提出了这个词）Test-driven design/development这样一个基于测试优先、重构和迭代的革命性的开发方法以来，无数的实践已经证明，对于适合进行TDD的领域，TDD能够极大地提高代码的可维护性和开发效率。

TDD的基本流程图如下：

在这样一个迭代的流程中，在写任何的production code之前，先写test，再写production code，并且不断地对代码进行清理和重构，并且每次迭代都要进行回归测试，保证新增的test和production code不会break任何已有的test和production代码。

一般来讲，支持自动化的回归测试的工具相对比较容易实现。整个流程中的难点在于：当先行写test代码的时候，必然要求先定义被测试的production code的外部接口，对于第一次迭代，自然没有问题；但是，由于需求的变更，或者整体设计的变更，在后续的迭代过程中，经常会发生，已有的已经实现并且包含完整测试的production code的外部接口需要变更或者说重构；尽管从理论上，绝大多数的重构需求，都有规律甚至是模式可循，但是，如果完全依赖于人工操作，则不仅效率不高，且极易出错。所以，但凡成功的TDD实践，其中都不乏很多支持重构的工具。比如，现行绝大多数的集成开发环境，都有很多自动化的代码重构工具，大大的降低了代码重构的成本。

但是还有一些领域，TDD还略微有些力不从心，或者说，至少，至今没有看到太多比较好的实践案例。比如：对于Database和UI。

对于数据库开发的TDD，到目前为止面临的主要挑战是工具的支持。无论是自动化的回归测试工具，还是重构工具都还远远不够成熟。

而对于UI的TDD，则是本文的主题。

TDD in HTML & JavaScript 概述

谈到应用程序的UI，其实包括两个方面的内容：一方面是纯图形的look & feel；另一方面，则是用户和应用程序的交互。用户和应用程序的交互往往同时导致图形界面的变化，并且，转换到新的交互行为。

由于工作实践中主要是基于WEB的HTML和JavaScript的项目，这里对TDD in UI的讨论，将focus在基于HTML和JavaScript的UI。

同时，一般来讲，WEB程序的表现层主要有客户端代码和服务端代码，而服务端代码，相对来说，更容易被测试。所以，本文讨论的重点，主要focus在客户端代码。换句话说，这里讨论的TDD in HTML & JavaScript指的是对于客户端的HTML和JavaScript的TDD。

TDD in HTML & JavaScript 之可行性

说到可行性，其实可以分两个层面：理论上的可行性，和实际应用的可行性。

第一个问题是：纯图形的look & feel理论上可以进行自动化的测试吗？答案几乎是否定的。因此，主要用于呈现纯图形的HTML及CSS，也几乎是很难自动化测试的。

那么，用户和应用程序的交互理论上是否可以进行自动化测试呢？答案毫无疑问是肯定的。

WEB交互的测试其实可以根据WEB程序的架构，分为两种类型：

传统的WEB程序主要基于服务端来呈现内容，用户和页面的交互，主要是get，post数据和页面跳转。因此，对应的测试方式，主要也是由测试工具模拟需要get或post的数据，并且跟踪期望的页面跳转情况。这种情况下的测试其实相对简单，因此本文不想过多讨论。
当前的基于AJAX的WEB程序则很大程度上丰富了用户和页面交互的方式，用户和页面的交互，除了传统的get，post数据和页面跳转，在页面不刷新的情况下，还通过触发各种DOM事件，甚至直接触发JavaScript方法的执行，由JavaScript来改变和呈现内容。此时，传统的只能模拟需要get或post的数据的测试工具就无能为力了。此时由于所有的逻辑代码都在JavaScript中，所以，本质上其实是需要对大量的JavaScript代码进行测试。此正是本文希望讨论的重点。

首先，针对JavaScript的自动化测试工具其实已经有不少了，如：

Mock工具也有：

支持直接重构JavaScript代码的工具相对比较少，提供的功能也都还非常弱：

从支持工具的现状，可以说，影响TDD in JavaScript的实际可行性的因素之一是重构工具的缺乏。

不过，最近的情况有了一些改变，现在也出现了一些支持JavaScript重构的变通的解决方案，如：

Script# - Write C# code，compile C# source code directly to JavaScript code
jsc – Write any .NET code, convert .NET assembly to JavaScript, ActionScript, java or PHP code

这些方案的特点是，利用现有的IDE对流行的编程语言如C#源代码的完善的coding，尤其是强类型，重构和测试的支持，让开发人员写C#，由工具转换为可直接执行的，格式化的JavaScript代码。除了充分利用IDE对流行语言的coding支持之外，这类方案的另一个好处是，相对于高薪聘请Senior的JavaScript开发人员，Junior的C#的开发人员要便宜得多，也易招得多，但得益于Script#，已经足够能用他们熟悉的C#，写出逻辑复杂和OO的JavaScript代码，因此，开发成本被大大降低。

综上所述，TDD in JavaScript不仅理论上是可行，实际应用上，也是有足够的工具支持的。尤其是如Script#这样的工具的出现，极大地提高了JavaScript代码的开发效率。

TDD in JavaScript 之最佳实践

谁都希望能有最佳实践。什么是最佳实践呢？有很多人见不得“best”，“最”这样的词，认为，这个世界上没有“最”的东西。有吗？当然有！我们首先要略为上升到哲学的高度，对于包含“最”这样的词汇的命题，如果想要为“真命题”，则必然是需要加上一个适当的前提条件的。

比如说：我说“我是这世界上最NB的人”。这毫无疑问是个假命题。因为，缺乏适当的前提条件。你可以自己做个练习，如果觉得这个命题假，想办法给它加上更多的前提条件，一定能让它变真。

所以，所谓最佳实践，指的是，对一个或者一类特定的问题，在一个相对确定的背景下，所能采取的实际处理的方案典范。加上前提条件，则“最佳实践”当然是存在的，也是值得讨论的。

通过前面的章节，我们已经把本文重点讨论的主题，限制到一个相对小的范围，那就是对基于AJAX的WEB应用程序中的大量的JavaScript代码，如何进行TDD？

并且，我们也收集了足够的支持TDD需要的各种工具，包括自动化测试工具，Mock工具和重构工具。在这些工具的支持下，很大程度上，WEB程序客户端JavaScript代码的TDD和服务端代码的TDD，不应该有很大的区别。但同时，由于客户端代码的特殊性，自然也应该有一些客户端脚本代码所特有的实践模式。

以下首先列出本人推荐的一些实践模式，希望大家能一起修正和补缺。

最佳实践一：应用MVC模式

在传统的非AJAX的WEB程序中，JavaScript往往处于非常辅助性的地位。除了实现一些特效和数据验证等辅助功能之外，一个页面的JavaScript代码，恐怕屈指可数，自然无所谓测试，甚至是TDD了。

但是在现在的复杂的AJAX应用中，以往必须由多个独立页面的get，post和页面跳转才能组合实现的功能，通过JavaScript，可以在一个无需刷新浏览器的页面中，轻易实现，不但用户体验更佳，速度更快，对服务器的负担也更小。

此时，原本传统WEB程序的服务端需要处理的问题，如数据绑定，事件绑定，逻辑控制等，需要在客户端进行处理。也因此，原本为了解决WEB程序服务端代码可测试性问题MVC模式，也就一样可以良好的应用于客户端。清晰的将JavaScript代码分割成M，V，C，将能够把相同的逻辑职责尽可能集中到一起来管理，从而极大地增加客户端代码的可维护性和可测试性。

下表简单对比服务端和客户端MVC下M，V，C的对应职责：

	Model	View	Controller
Server Side	返回用于呈现页面内容的数据的 Domain Objects	代表了一个页面的抽象，包括页面的内容呈现，数据，事件定义	处理View上触发的事件，获取数据，更新View上的数据，触发View的内容呈现
Client Side	返回 JSON 数据的 Restful Services	同上	同上

最佳实践二：应用依赖注入和IoC容器

应用MVC模式，本质上是抽象的逻辑职责上的解耦。而依赖注入和IoC容器则是代码的物理依赖性上的解耦。尽可能的利用构造器注入，设值注入，接口注入或IoC容器来解除具体的实现类之间的直接依赖，自然就能极大的大提高每个具体的实现类的可测试性。

最佳实践三：应用模板引擎呈现主体内容

AJAX应用中的一个需要客户端呈现的View，必然需要呈现一些HTML，这些HTML往往需要根据Model返回的JSON数据动态构造。一般来讲，我们会有三种方式来构造和呈现这些HTML：

在JavaScript中遍历JSON数据，拼接HTML字符串，呈现到页面上；
在JavaScript中遍历JSON数据，动态实例化DOM对象，通过DOM对象的方法，呈现HTML的DOM；
通过如JTemplate这样的JavaScript模板引擎，将JSON数据绑定到一个HTML模板，由模板引擎呈现最终的HTML；

本最佳实践的建议内容就是，对于一个View的主体内容，应该尽可能的通过模板引擎来呈现。为什么呢？因为，对于一个WEB程序来说，最不稳定的，会经常变化的部分，无疑是纯图形的HTML和CSS，使用模板引擎，将能够使得这些HTML尽可能的集中，并且易于修改，也更易于HTML和JavaScript的整合。

最佳实践四：应用Script#

应用Script#好处前面已经提过了，这里再简单列举一下：

充分利用现有的IDE对流行的编程语言如C#源代码的完善的coding，尤其是强类型，重构和测试的支持；
相对于高薪聘请Senior的JavaScript开发人员，Junior的 C#的开发人员要便宜得多；

如反对，请列举我不该用它的理由？

对于以上几个最佳实践的应用实例，请参见我之前的文章：This is jqMVC# – CNBLOGS Google Tracer Sample。

欢迎补缺、指正！谢谢！

本文链接

突然发现想在博客园发起一个有价值的讨论其实很难

2010-07-10T12:56:00Z

为什么会有如题的感叹呢?
其实,我们本来只是想和大家探讨一下TDD in HTML & JavaScript的可行性和最佳实践.

首先想到用blog,可是,既然我只是想讨论,如果写一个blog一定很短,并且没有直接有价值的内容,所以,往首页放貌似是不合适的.但是不放首页其实没有几个人能看到的.就算我厚脸皮放到首页,也是很快就会被沉下去的.

那么,别的呢?

博问?看起来只是给新手问问题的?

小组?我不得不先加入一个小组,但是,我能发到多个小组吗?貌似不行,因为毕竟不是论坛的分类.好吧,就算我不介意选择一个小组加入.看看所有小组最近更新,最近6小时内只有8个回复.这样的整体活跃程度,我很难想象我期待的讨论能起到效果.

闪存?很推特,但是,很不合适讨论稍复杂一点的问题.

没有了.

//其实,我本来想给dudu发这样一个站内短信.但是打了不少字,发个短信觉得有点可惜了.所以,厚脸皮放博客首页一会儿和大家讨论一下吧,其实很快也就沉下去了~~ :]]

本文链接

This is jqMVC# – CNBLOGS Google Tracer Sample

2010-07-01T15:54:00Z

In previous post - This is jqMVC# - Definition & Summary, I briefly introduced what is jqMVC#. In this post, I’ll show you a “CNBLOGS Google Tracer” sample application which is applying the jqMVC# architecture.

Function

The testing results of QUnit:

Source Code

You could download the latest source code of this demo from SVN: http://nintegrate.googlecode.com/svn/trunk/jqMVCSharp/

or download this zip file: jqMVCSharpDemo.zip

To open the project files in Visual Studio 2008, you should install Script# 0.5.6 for VS 2008 first.

本文链接

This is jqMVC# - Definition & Summary

2010-06-19T17:08:00Z

Before discussing more, please realize what I’m talking about is not “theoretical research”, but “real successful practice”.

Definition

I created the word – “jqMVC#”, which means bunch of things:

“j” means it is about JavaScript;
“q” means it is about jQuery & jQuery plugins;
“MVC” means it is about MVC pattern;
“#” means it is about C#;
“j”+”#” means it is about Script#;

Another thing which is not directly represented by the word but implied is TDD in JavaScript but whose code is written in C#.

When all these things come together, it is jqMVC# – a new practical architecture which makes enterprise-level HTML & JavaScript only rich UI development in B/S-architecture application become not only possible, but also as a representative of HTML5 with which we could really say ‘Good bye!’ to Flash & Silverlight even now for most cross-browser web applications which do not really require those complex animation effects.

Summary

In this summary, I’m trying to talk a little bit more for each of the items I mentioned in previous section to make this architecture look more conceivable.

Firstly, our JavaScript code is written in C# with the help of Script#. Script# could compile C# source code to JavaScript automatically. The biggest benefit here is, even a junior developer who is familiar with C# but only know a little of JavaScript could write huge OO JavaScript code efficiently.

Secondly, the M, V, C classes implementing the MVC pattern in client-side JavaScript are written in C# and are compiled into JavaScript through Script# automatically.

Why MVC?

Two main benefits:

1. Separations of data, controlling and presentation;

2. Easier for unit testing;

In JavaScript, when we implementing MVC pattern,

Models are JSON comes from server-side services through AJAX and JSONP communication, which should be under TDD in server-side coding;
Controllers are Script# classes focus on the controlling of Models and Views, which should be under TDD in Script# coding;
Views are as connectors between pure HTML & JavaScript code and Script# based Models & Controllers code, which should also be under TDD in Script# coding;

Thirdly, jQuery & jQuery plugins are wrapped by Script# together with the Script# predefined libraries as the main tool libraries for client side UI rendering & controlling. Especially, jTemplate is used as the main HTML rendering engine. QUnit is also wrapped by Script# and used as the client-side testing library to implement client-side regression testing which is the core of client-side TDD.

To be continued…

In next post, I’m going to give a simple but runnable example to demonstrate the benefits of applying jqMVC# architecture.

本文链接

Discuss some new features in WCF 4.0

2010-04-25T13:28:00Z

This article discusses my understanding of some new features in WCF 4.0 and how NIntegrate could work with WCF 4.0.

1. Configuration Based Activation

“Configuration based activation” means, instead of creating a physical .svc file for a WCF service be hosted in IIS, you could now set the equivalent configuration in the new <serviceActivations> element in <serviceHostingEnvironment> configuration section in the Web.config file.

It is an alternative of physical .svc files, and enables centrally management for the hosted WCF service addresses of a WCF host application. But it still does not support programmatically load the configuration of the <serviceHostingEnvironment> configuration section, which means, it is still impossible to store them in a central configuration store, such as in database, for all your WCF host applications.

Remind you that, since even before WCF 4.0, there is one possible but limited approach to host WCF services in IIS without physical .svc files and even centrally store the addresses in anywhere, such as in database, which is through “VirtualPathProvider”. The limitation is it supports only HTTP bindings. In some previous version of NIntegrate, I used to provide one custom VirtualPathProvider implementation to manage WCF service addresses in database and deployment centrally. But I removed it in later versions of NIntegrate because it is not very hard to be implemented by yourself. Here I just advise you that you may want to consider this approach especially when your WCF application is RESTful only or uses HTTP bindings only.

2. System.Web.Routing Integration

“System.Web.Routing integration” allows you to host a WCF REST service that responds to URIs without an extension easier. Even without System.Web.Routing, it is also possible to “host a WCF REST service that responds to URIs without an extension ”, although with routing, it becomes much easier. Most of you should begin familiar with the routing ability of ASP.NET since the ASP.NET MVC framework. It is really attractive and helpful when you widely use WCF to implement RESTful services.

But do you even think “widely use WCF to implement RESTful services” is a good idea? OK, there are debates. Personally I’ll not use WCF to implement RESTful services, even now in WCF 4.0, there are lots of improvements for RESTful WCF services. A better way should be “use ASP.NET MVC 2 to expose RESTful services”. I’ll discuss more below when discussing the new features WCF 4.0 provided for RESTful WCF services.

3. Routing Service

First of all, please realize that “The Routing Service does not currently support routing of WCF REST services”. “Routing service” here means a new predefined WCF service in WCF 4.0 which implements the Intermediate Routing pattern, generically supports routing SOAP based WCF service messages to their destinations based on a set of customizable rules. This pattern is an important enterprise SOA design pattern which solves the problem that, for large and complex service composition, it is difficult to design service contracts for all possible runtime scenarios in advance.

4. Support for WS-Discovery

The Service Discovery feature enables client applications to dynamically discover service addresses at runtime in an interoperable way through WS-Discovery specification. The WS-Discovery specification is an OASIS standard, which means it is possible to exchange metadata with 3rd party WS-Discovery implementation, although I believe most people just needs the ability to discover services at runtime.

NIntegrate provides a programmatic object model for hosting WCF services, and also for client to discover WCF services at runtime easily. So for the ability of discover services, it should be more flexible than WS-Discovery. But since the core of the the WCF 4.0 WS-Discovery implementation – the discovery endpoint and behavior classes are standard WCF endpoints and behaviors, it could be used together with NIntegrate to give you the benefits of both.

5. WCF REST Enhancement

Fairly speaking, WCF 4.0 enhanced much a lot for RESTful services: output caching, dynamic response format & JSONP support, error handling and routing without extension. In WCF 3.5 where without the WCF 4.0 new features, using WCF to implement RESTful services is not easy. But there are some official & 3rd party extensions providing RESTful features such as output caching, JSON & JSONP response and routing without extension. Technically, WCF 4.0 makes all these features be official and easier to use, but it is still not enough reason to use WCF to implement RESTful services for me. Personally, I prefer to use ASP.NET MVC 2.

Below are the reasons I like ASP.NET MVC 2 more than WCF for implementing RESTful services:

1) Configuration and deployment cost

Although in WCF 4.0, more predefined standard endpoints make it easier to use. It still needs configuration, and also needs deployment effort.

In ASP.NET MVC 2, no special configuration and deployment effort for each RESTful service is required.

2) Output caching

WCF 4.0 has enhanced a lot here, but ASP.NET MVC 2 still has the maximal flexibility & extensibility for output caching.

3) JSON & JSONP

For JSON response, ASP.NET MVC 2 is easier to be integrated with 3rd party serializers such as JSON.NET. For JSONP support, with the JSONPModule provided by NIntegrate, any JSON (XML response could be automatically converted to JSONP soon in next release) response services could automatically have the cross domain AJAX ability without any additional effort.

4) Error Handling

Error handling in WCF RESTful services is still limited by the WCF FaultException design, while in ASP.NET MVC 2, it is much more flexible and easy to control.

5) Routing

You smile when I try to compare the routing ability of WCF and ASP.NET MVC 2.

In summary

Any of the enhancement in WCF 4.0 for RESTful services is not as flexible and powerful than in ASP.NET MVC 2, and even leverages from ASP.NET MVC by design. Give me a reason to use WCF RESTful services then?

本文链接