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