《企业应用架构模式》读书笔记(一)

来源:百度文库 编辑:神马文学网 时间:2024/03/29 14:29:45
企业应用架构模式读书笔记(一) 前年走马观花式的把这本书读了一遍,加上当时并没有实际使用,所以时隔不到两年,对本书中部分内容的印象已经有些模糊了。最近要用到这方面的知识,花点时间再读一遍,顺便记点笔记。 企业应用的特点:需要持久化数据。存在大量数据。支持大量用户并发访问。涉及大量操作数据的用户界面。 关于性能的几个概念:响应时间。响应性。等待时间。吞吐量。负载。负载敏感度。效率。可伸缩性。 关于模式:模式是“半生不熟品”,你需要自己加上最后一把火。所以同一个模式在不同的使用场合,看似相似,又各有不同。 本书第一章主题是分层。根据这些年的经验和所学到的知识,窃以为设计的中心就是减小系统的复杂度,而减小系统复杂度的方法无非就是:分层、分治、抽象。作者把分层放在第一章,我觉得这是极为合理的。 三个基本层次:表现层。领域层。数据源层。 后面两层绝对不允许含有表现层的代码,原因是界面是最容易变化的,设计的重要目标就是把可变的东西隔离起来,让它独立变化。 如何判别表现层和领域层是完全分离的?好办,重新实现一个风格完全不同的表现层,比如把基于WEB的表现层,换成基于命令行的表现层。如果两种表现层中几乎没有重复的代码,那恭喜你,你的设计是表现层和领域层完全分离的。 如何让表现层与领域层分离?这个问题已经问老了,去看看MVS模型,去看看MFC的文档视图模型,去看看订阅-发布设计模式,它们差不多是同一个东西。 如何判别领域层和数据源层是完全分离的?与判别表现层和领域层的方法类似,重新实现一个数据源层,如果以前采用的SQL数据库服务器,现在换成XML试试,如果轻而易举的就做到了,同样恭喜你,领域层和数据源层是完全分离的。 领域层部署在服务器还是在客户端,看你具体的选择了,不过最好是不要把它的一部分放在服务器上,另外一部分放在客户端。如果真的这样做,让这两部分尽量各自独立,不要依赖关系太强。 Alan Knight说,将部分领域逻辑混入表现层,到底是滑向地狱的第一步呢,还是只是少数纯粹主义者才会抱怨的小问题?作者说,我们之所以担心,正是因为这种做法两者兼备。呵,回答得够绝。 组织领域逻辑的三种模式:事务脚本。领域模型。表模块。我的理解是: 事务脚本就是传统的面向过程的方法。以过程为中心,直观的说是以动作为中心的。比如在超市收银台买单时的过程,可以描述为一系列的动作:录入商品代码。       计算总价值。       收款。       找零。 领域模型就是完全面对对象的方法。以对象为中心,直观的说是以物品为中心。如如上面的例子可以描述为:       创建一个帐单对象。       一一的创建商品对象,并加入帐单对象。       帐单对象提供一个买单的方法,输入付款数,返回找零。 在这里,帐单和商品是对象,也是中心,动作不过是这些对象的行为罢了。 表模型介于上述两个模型之间,可以认为它是基于对象的方法。初看有些像领域模型,对象的数据是集中在一起的,相关的操作也是集中在一起的。但是它并不存在继承和多态性,常常不能直接使用策略等面向对象的设计模式。 选择三种模式的标准是系统的复杂度和环境。简单的情况可以采用事务脚本,复杂的情况首选领域模型,开发环境对记录集支持得好,可以选择表模块。 但对于复杂度没有量化的标准,通常只能根据开发者的经验判断。作者开玩笑说,当复杂度超过7.42时就选择领域模型,但是你没有办法知道什么样的复杂度是超过7.42的。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/absurd/archive/2006/05/15/740031.aspx