Martin Fowler这本《企业应用架构模式》应该是家喻户晓了，买了也有些日子，一直没有拿起来看，现在终于轮到了这本书。

这本书大致分为两部分，前8章为{dy}个部分，对企业级开发要涉及的东西进行初步的介绍，然后还概括性的讲解了一些模式的适用场景和优缺点。第二部分是模式的列表，这些模式的分类就是按照{dy}部分介绍的企业级开发要注意的方面来分的。现在我只看完了{dy}部分。

在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:与其他系统集成，别说了，我现在还在为这个苦恼呢，现在正在做一个集成的东西。如果所有系统都是我们一家开发的倒好说，现在各家开发的，使用的技术也千奇百怪，这个倒好说，各家扯起皮来头就痛。

上面虽然举出了很多特征，但是只有少数比较有感触，感触最多的还是业务逻辑的复杂性，做企业级应用的{zd0}的难点我觉得应该是一帮IT人员去跟一帮别的行业的用户打交道，我记得刚工作那会儿，头头带着我去现场，客户谈的天花乱坠，我就像一个傻瓜，什么采收率、什么剩余油分布我是一个也听不懂，没办法，后来买几本石油的书自己看。还有一个感触是，企业级应用里技术比较落后，一切都讲究稳妥。还有在扩展方面，因为企业有钱，在某些东西遇到瓶颈的时候都以购买性能更好的硬件来解决，很少有横向扩展的方式，所以很郁闷的不能尝试一些很潮的架构（比如老赵最近写的关于以及的几篇文章）。

在本书的{dy}章，讲的就是分层，澄清了一些概念：layer与tier的区别。Layer一般指的是逻辑分层，比如我们说的UI、BLL、DAL。Tier指的是物理分层，一般作为开发人员我们更多关注逻辑分层，也就是Layer。

在这里还是离不开那个经典又该死的三层架构。这里列出了一张表：

在这里没什么说的，就是这个领域层，在工作之前，我做的东西都是Web，而且大部分还是什么新闻啊，论坛之类的。那个时候天天看这个三层架构，为啥就多个业务逻辑层呢，没啥逻辑啊，但是为了“证明”我是用的三层架构，我就也添加了一个业务逻辑层，但实际上那个层仅仅就一个Proxy，将界面调用过来的方法直接传递给数据访问层。二层就够了，那个时候实际上没有理解分层的意义，不要为了分层而分层，分层是为了划分层与层之间的职责，划分层的边界，将变化抑制在层内，不要层间扩散。如果简单到只需要两层，那就两层呗。

不过工作了却不一样了，现在做的系统，写代码最多的地方就是业务逻辑层，所以这个层的职责也就体现出来了。

在这里Martin还教了一个方法来判断，哪些东西该放到业务逻辑层，哪些是界面上的逻辑：

添加一个相同的层，比如你现在做个web应用，是不是已经有个展示层了，那你还添加一个展示层，这次用控制台的方式来实现展示层，你看看用HTML方式的展示层和控制台的方式实现的展示层之间有哪些重复的代码，将重复的代码转移到业务逻辑层中去吧。

呵呵，这个方法对你可能没啥用，对我确实不错，貌似也一直这么干的，我们的系统大部分都是B/S和C/S的都要开发，所以。。。。。

第二章介绍的是如何组织业务逻辑。Martin总结了三个主要的模式：事务脚本、领域模型、表模块。

实际上这三个模式对应的就是面向过程、面向对象、面向数据库。惊叹Martin的忽悠能力。

事务脚本？啥是事务脚本？实际上就是你常常干的，拼装个SQL语句，搞个查询，返回个啥，这种过程方式。
而领域模型呢，就是按照职责，建几个类，每个类仅仅负责自己的职责那部分，对象与对象之间有机的组织在一起。
表模块，实际上就是每张表搞一个类，一个单例的类，负责该表相关的操作。

第三者我没怎么用到，对于前两者，很多人在意识上抵触事务脚本，说这种是过程化的产物。但实际上对一些简单的应用，比如报表，业务逻辑非常简单，直来直去的，还不是经常变化，那事务脚本就是{jj1}的啊，你还搞几个对象累不累。

而当业务逻辑有点不确定，比如里面还有根据什么东西的类型然后决定执行什么操作的代码，那你就不要搞一堆的if else或switch出来了，搞个对象层次来处理这个吧。但是做领域模型的时候，你首先要花点思考职责的问题，什么对象负责哪一个都想一想。

第三章，映射到关系数据库，这可是个大话题。这一章篇幅也比较大，讲了很多实际开发中要面临的问题。

在说Martin的之前我先说几点我碰到的问题：

1、要支持多种数据库，这个做项目还好，做到产品就要求支持Oracle、SQL Server、Sysbase，有的时候还要支持Access做单机应用。即使是相同的数据库，还要支持不同的版本，比如有一次在某油田实施，系统老连接不上去，{zh1}没办法现场调试一下呗，{zh1}找到问题是他们用的数据库还是Oracle 6，而我们产品开发的时候用的是Oracle 10g，幸亏用的是IBatis.Net，改一下就ok了。

2、数据库已经定了，这个我相信很多做企业级开发的都碰到了，都是针对遗留数据库开发，里面有很多历史数据，不可能要求你重新设计，特别郁闷的是有的数据表设计的及其不合理，你还不能改。有一次我碰到一个表，实际上可以分成三张表，但是都放在一张表里，形成一种“扁平”的结构，我百思不得其解，难道当初设计这数据库的人这么菜么，{zh1}一问，这是因为这张表的数据通常是用传感器采集到数据，然后通过一个专门设备存库的，那个嵌入式设备存这种扁平的结构比较好存，my god。

3、离线应用，这个也是很多用户强烈要求的，说如果背个电脑到领导那儿汇报演示，以前都用PPT，领导想看点别的数据看不了，现在既然有你这软件了，那就用这软件直接演示吧，但是领导那儿总不好把人家网线给拔了吧，或者出差的时候连不上企业内部网络等，嗯这也是比较xx的问题。

上面这是我经常碰到的问题，总结一下。

Martin对映射到关系数据库这一块儿讨论比较多，而且我也觉得映射到关系数据库也是日常开发中的重头戏，所以在本篇文章中就到此位置吧，下篇文章再仔细谈谈一些注意事项。

买书不看就是浪费，这本书买了一年有多，还是新的一样，罪过罪过。确确实实的体会到谁说的那句话，现在缺的不是书，是看书的人。