快到2009年了，按公司要求，用了当当购书卡，要写两篇读书笔记，其实200块早就用完了，我看了很多书，还是选两本个人感觉意义更大一点的，一本是本文中说的，另一本准备写《狼图腾》。

本书主要讲解了“CSLA.NET”框架，本书封面上一句话很牛“架构、设计和开发极具可扩展性和可维护性的面向对象商业应用”，的确，通过框架和示例项目的讲解，证明了这一点。

曾几何时，这么多年，我一直在寻找一个好的框架。以前，我们项目做的不好，首先就说需求分析做的不好，要不就说架构不好。是的，任何项目失败，都不能怪程序员，首先应是项目经理的责任。需求分析这一块主要是看分析员的水平，以及客户的配合程序，分析员经验丰富，熟悉项目的领域，一般也能需求上写的够细，用例、功能点表达完善，我觉得就够了。但架构这一块，或者说主体采用什么样的框架完成软件，不同的架构师，不同的团队可能选择的技术不同，面对现在软件五花八门的技术、组件，以及社区出现的各种框架技术，我们搭建框架时，选择现有的东西很重要，当然要选择适合团队的，一些最新的技术，看不去很美，但真正实施后，要考虑到风险，特别是开发人员不熟悉的东西，不能完全掌控的东西，我觉得千万不能用，不然出了问题，怎么解决都不知道。

就拿我们开发一个基于.NET，SQL 2005的B/S结构的网站来说，要用到的技术有，表现层的HTML，CSS，JavaScript，ASP.NET，AJAX。业务层（包括数据访问层）有C#，面向对象，ADO.NET，可能还会有缓存。数据库SQL Server2005，TSQL，可能还会用到存储过程，函数，视图等等。而框架的作用就是如何组织好这些技术，使之关联起来，并且能够有很好的扩展性，以使将来需求发生改变时，如更换表现层，用WinForm，用PDA等等。如更换数据库，换成Oracle，MySQL等 ，改变部署，能够使用分布式，夸张一点，表现层在美国，业务层在上海，数据库在北京等等，再夸张一点，现在网站的访问量特别大，要引入Web负载均衡，数据库要集群，这时候，框架的作用就能体现出来，如果一开始考虑不完善，往往到后期有些需求就会无法满足。当然，我们做项目，主要还是以客户的需求为准，不会一开始把事情搞得太复杂，但如果有一套伸缩性很强的框架，用了之后，会使项目的成功和以后的发展有很大的帮助。

CSLA.NET是我看到过的框架中感觉是最强大的，强就强大在他的“分布式”，分布式在现在信息化时代非常重要，淘宝没有分布式，他不会这么快，能支持这么多的用户。所以，马云会自豪的说“现在企业要在上面开家商铺，几乎没什么成本，最多再加几台服务器”。如果一开始程序没有分布式，单台服务器的运算能力是有限的，CPU和内存到一定程度，基本上就到顶了，只有分布式，引入多台服务器，对用户进行分流，20台PC机的价格可能都达不到一台好点的服务器的价格，但同时在一起的运算能力肯定会强于一台服务器，而且稳定性上也强，坏了一个，还有好多其它顶着，如果是一台服务器，出了问题，就彻底挂了。

我从一本书上看到过，框架的定义，第一，要有专人维护，以不断跟过最新的技术，并不断的解决人们提出的Bug，CSLA框架是由LHOTKA专门维护的，现在的版本已经发展到3.6了。第二，要有专门的文档说明框架如何使用，作者为每一个重要版本都出了书，2.0的框架就是现在这本书，基于.NET 2.0的技术，3.6版本框架的书英文版的《Expert C# 2008 Business Object》从作者的网站上看，12月就要印刷出版了，电子版现在已在销售了，“老外真能赚钱，这也是软件的价值的一种体现”，中文版估计还要等好一段时间。第三，有文档说明修改了那些东西，就是Change Logs，作者专门有一个网站，http://www.lhotka.net 作者专门有Blog列表，记录修改的所有东西，当然，网站还有论坛讨论技术，讨论框架使用过程的问题，解决方案。

我觉得使用这样一个框架，是让人放心的，这个框架是开源的，免费的，可以用于商业目的的，无需付费的。我们不用担心遇到问题解决不了，更有多种代码生成工具，大大方便了开发，提高了开发效率。因为，对于底层的那些Set，Get，CRUD操作实际上工作量也很大，大量的写这些东西，程序员也会反感，人参与的多了，出问题的机率就多了。

我们知道一个面向数据的管理软件，无外乎就是操作数据库，然后把读出来的内容，七拼八凑美化一下，放到界面上，程序界面最终与用户交互，搜集数据，再去回写数据库，保存数据。所以，现在开发软件很容易，是个人都会拖拖拉拉开发了，但真正做到企业级，我估计没有好的架构，框架就会很吃力了，随着代码量不断增多，逻辑不断复杂，维护将会越来越难，到最后，可能大到不想维护了，后来的人，不敢乱动前面的，“牵一发而到全身”，真正到了《人月神话》里的“焦油坑”，投入再多，也被无情吞没。

CSLA.NET框架很好的注重了分层，有效的组织代码，但我感觉最重要的还是实现分布式，实际上就是序列化对象和复制对象技术。书名中的“Business Object”，就是强调业务对象，业务对象包含了对象的逻辑和数据访问代码，将业务对象通过不同的远程调用技术传输就实现了分布式，在2.0中可以用Enterprise Services，Remoting，Web Service，在3.0中又加入了WCF通道技术。当然，为了考虑到性能，单机部署时，就可以省去对象传输的过程，直接调用本地的业务对象。表现层和应用层之间是采用数据门户的概念，在配置文件中决定何种访问方式，修改部署很方便，要实现分布式，直接在服务端简单建一个宿主，在配置文件中配置一下，整个项目代码都不用改。

下面的图是从电子版中截取。

聪明的业务对象

数据门户调用，客户端代理传递业务对象给服务端门户，LocalProxy没有传递过程，本地直接调用，提高性能。

当然，作者还考虑了安全性方面，分布式事务，传递客户端上下文，数据绑定等技术。本书前半部分在讲框架的原理和实现，在讲解一个问题的同时也会比较其它方案，分析其它方案的优缺点，这种务实的态度我觉得是非常好的。后半部分在讲框架使用，讲述了一个Project Tracker的项目开发过程，从数据库设计到业务类实现，再到WinForm表现层，Web From表现层，最后，通过修改配置文件来实现远程数据门户，这样，就真正实现了分布式。

当然，这本书要看完，还是要一定程序的技术功底的，我看了3，4遍，主体思想能明白，细节上还要再看，真的，里面的n层撤销其实用到的技术也是比较牛的。每修改一下形成一个版本，撤销就还原到上一个版本，最后再持久化到数据库。

最近，我还看了一本《JavaScript 高级程序设计》，《征服ASP.NET 2.0 AJAX》，使我越发觉得基础技术的重要，我们不要被所谓的新技术迷了眼，其实最简单的才是最好的，看到现在，好多人，赶时髦，乱用技术，真的感到“无知者无畏”。还是打好基础吧，还是牛人候捷说得好 “万丈高楼平地起，勿在浮沙筑高台”，我们做技术还是踏实一点，不要浮躁，多学点基础吧。