企业应用架构模式读书笔记（一）
本文转自：http://www.cnblogs.com/yuyijq/archive/2010/03/13/1684938.html
Martin Fowler这本《企业应用架构模式》应该是家喻户晓了，买了也有些日子，一直没有拿起来看，现在终于轮到了这本书。
这本书大致分为两部分，前8章为第一个部分，对企业级开发要涉及的东西进行初步的介绍，然后还概括性的讲解了一些模式的适用场景和优缺点。第二部分是模式的列表，这些模式的分类就是按照第一部分介绍的企业级开发要注意的方面来分的。现在我只看完了第一部分。
什么是企业级开发
在Introduction一章里，Martin对“Enterprise Application”的说法倒是很有意思：很多人觉得“企业级应用”就是大的系统，但实际上并不是所有的企业级应用都大，即使它们为企业提供了很多价值。
Martin的理由是，企业级应用关注的是领域的业务逻辑，这个业务逻辑非常复杂，而对比如电信行业的系统大吞吐量、高并发关注的比较少。
Martin说：“Enterprise applications often have complex data-and lots of it-to work on,together with business rules that fail all tests of logical reasoning.”
针对企业级应用的特点，Martin总结出一些共有的特征：
Persistent data:一般企业级应用都要将数据持久化起来（不过这个，貌似当今的大部分系统都是如此）
a lot of data:数据量大，这个也许比起当今的Web 2.0网站，有点小巫见大巫了，不过也看什么行业吧
access data concurrently:并发访问数据，这个我倒是没怎么感觉，我是做石油行业软件开发的，即使用户同时在线也不过一两百人，谈不上高并发
事务:这个倒是真的，一般企业级应用我想都跟钱有很密切的关系，事务处理貌似很常见（个人感触）
a lot of user interface screens:许多用户界面，这个也是，一个系统密密麻麻的界面，不过有人说当今的Web 2.0应用界面更多啊，那个海量啊。不过Web 2.0的网站界面是多，但大部分是相同的，只是数据不同而已，而企业级应用里就是一堆堆不相同的界面
用户技术层次不高:这个说到我心坎上了，企业级应用一般面对的都是别的领域里的人，他们跟我们IT人员的思维很多不一样，这个是个比较麻烦的事儿
integrate with other enterprise applications:与其他系统集成，别说了，我现在还在为这个苦恼呢，现在正在做一个集成的东西。如果所有系统都是我们一家开发的倒好说，现在各家开发的，使用的技术也千奇百怪，这个倒好说，各家扯起皮来头就痛。
上面虽然举出了很多特征，但是只有少数比较有感触，感触最多的还是业务逻辑的复杂性，做企业级应用的最大的难点我觉得应该是一帮IT人员去跟一帮别的行业的用户打交道，我记得刚工作那会儿，头头带着我去现场，客户谈的天花乱坠，我就像一个傻瓜，什么采收率、什么剩余油分布我是一个也听不懂，没办法，后来买几本石油的书自己看。还有一个感触是，企业级应用里技术比较落后，一切都讲究稳妥。还有在扩展方面，因为企业有钱，在某些东西遇到瓶颈的时候都以购买性能更好的硬件来解决，很少有横向扩展的方式，所以很郁闷的不能尝试一些很潮的架构（比如老赵最近写的关于Key/Value数据库以及数据分区的几篇文章）。
分层
在本书的第一章，讲的就是分层，澄清了一些概念：layer与tier的区别。Layer一般指的是逻辑分层，比如我们说的UI、BLL、DAL。Tier指的是物理分层，一般作为开发人员我们更多关注逻辑分层，也就是Layer。
在这里还是离不开那个经典又该死的三层架构。这里列出了一张表：
| 分层 | 职责 |
| 展示层 | 提供服务，显示信息（比如窗口里和HTML里，处理用户请求，HTTP请求等 |
| 领域层 | 逻辑，系统的真正核心部分 |
| 数据访问 | 与数据库啊、消息系统、事务管理器以及其他系统通信的部分（不仅仅是操作数据库哦） |
在这里没什么说的，就是这个领域层，在工作之前，我做的东西都是Web，而且大部分还是什么新闻啊，论坛之类的。那个时候天天看这个三层架构，为啥就多个业务逻辑层呢，没啥逻辑啊，但是为了“证明”我是用的三层架构，我就也添加了一个业务逻辑层，但实际上那个层仅仅就一个Proxy，将界面调用过来的方法直接传递给数据访问层。二层就够了，那个时候实际上没有理解分层的意义，不要为了分层而分层，分层是为了划分层与层之间的职责，划分层的边界，将变化抑制在层内，不要层间扩散。如果简单到只需要两层，那就两层呗。
不过工作了却不一样了，现在做的系统，写代码最多的地方就是业务逻辑层，所以这个层的职责也就体现出来了。
在这里Martin还教了一个方法来判断，哪些东西该放到业务逻辑层，哪些是界面上的逻辑：
添加一个相同的层，比如你现在做个web应用，是不是已经有个展示层了，那你还添加一个展示层，这次用控制台的方式来实现展示层，你看看用HTML方式的展示层和控制台的方式实现的展示层之间有哪些重复的代码，将重复的代码转移到业务逻辑层中去吧。
呵呵，这个方法对你可能没啥用，对我确实不错，貌似也一直这么干的，我们的系统大部分都是B/S和C/S的都要开发，所以。。。。。
组织业务逻辑
第二章介绍的是如何组织业务逻辑。Martin总结了三个主要的模式：事务脚本、领域模型、表模块。
实际上这三个模式对应的就是面向过程、面向对象、面向数据库。惊叹Martin的忽悠能力。
事务脚本？啥是事务脚本？实际上就是你常常干的，拼装个SQL语句，搞个查询，返回个啥，这种过程方式。
而领域模型呢，就是按照职责，建几个类，每个类仅仅负责自己的职责那部分，对象与对象之间有机的组织在一起。
表模块，实际上就是每张表搞一个类，一个单例的类，负责该表相关的操作。
第三者我没怎么用到，对于前两者，很多人在意识上抵触事务脚本，说这种是过程化的产物。但实际上对一些简单的应用，比如报表，业务逻辑非常简单，直来直去的，还不是经常变化，那事务脚本就是绝佳的啊，你还搞几个对象累不累。
而当业务逻辑有点不确定，比如里面还有根据什么东西的类型然后决定执行什么操作的代码，那你就不要搞一堆的if else或switch出来了，搞个对象层次来处理这个吧。但是做领域模型的时候，你首先要花点思考职责的问题，什么对象负责哪一个都想一想。
映射到关系数据库
第三章，映射到关系数据库，这可是个大话题。这一章篇幅也比较大，讲了很多实际开发中要面临的问题。
在说Martin的之前我先说几点我碰到的问题：
1、要支持多种数据库，这个做项目还好，做到产品就要求支持Oracle、SQL Server、Sysbase，有的时候还要支持Access做单机应用。即使是相同的数据库，还要支持不同的版本，比如有一次在某油田实施，系统老连接不上去，最后没办法现场调试一下呗，最后找到问题是他们用的数据库还是Oracle 6，而我们产品开发的时候用的是Oracle 10g，幸亏用的是IBatis.Net，改一下就ok了。
2、数据库已经定了，这个我相信很多做企业级开发的都碰到了，都是针对遗留数据库开发，里面有很多历史数据，不可能要求你重新设计，特别郁闷的是有的数据表设计的及其不合理，你还不能改。有一次我碰到一个表，实际上可以分成三张表，但是都放在一张表里，形成一种“扁平”的结构，我百思不得其解，难道当初设计这数据库的人这么菜么，最后一问，这是因为这张表的数据通常是用传感器采集到数据，然后通过一个专门设备存库的，那个嵌入式设备存这种扁平的结构比较好存，my god。
3、离线应用，这个也是很多用户强烈要求的，说如果背个电脑到领导那儿汇报演示，以前都用PPT，领导想看点别的数据看不了，现在既然有你这软件了，那就用这软件直接演示吧，但是领导那儿总不好把人家网线给拔了吧，或者出差的时候连不上企业内部网络等，嗯这也是比较头痛的问题。
上面这是我经常碰到的问题，总结一下。
Martin对映射到关系数据库这一块儿讨论比较多，而且我也觉得映射到关系数据库也是日常开发中的重头戏，所以在本篇文章中就到此位置吧，下篇文章再仔细谈谈一些注意事项。
题外话
买书不看就是浪费，这本书买了一年有多，还是新的一样，罪过罪过。确确实实的体会到谁说的那句话，现在缺的不是书，是看书的人。