企业应用架构模式读书笔记(一) - 横刀天笑的技术空间- 博客园

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

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


郑重声明:资讯 【企业应用架构模式读书笔记(一) - 横刀天笑的技术空间- 博客园】由 发布,版权归原作者及其所在单位,其原创性以及文中陈述文字和内容未经(企业库qiyeku.com)证实,请读者仅作参考,并请自行核实相关内容。若本文有侵犯到您的版权, 请你提供相关证明及申请并与我们联系(qiyeku # qq.com)或【在线投诉】,我们审核后将会尽快处理。
—— 相关资讯 ——