Hunter的大杂烩 技术学习笔记

http://happyprogram.cnblogs.com/archive/2005/07/18/195219.html

第四章 Web表现层
表现层有很多种具体的表现形式：Web页面、Windows对话框、命令行、手机屏幕等等。作者讨论表现层时，集中于Web表现层。虽然Web应用不会完全替代其他的表形形式，但毫无疑问，它是未来的主流之一。

准备开发一个Web应用，从服务器端软件开始。构建Web服务器上应用程序的方法主要有两种：一种是使用脚本，另一种是使用服务器页面。脚本形式是一个程序，它调用函数或方法来处理HTTP的请求，并将Html结果通过流输出到客户端，这样的例子包括CGI脚步和Java servlet等。服务器页面采用在Html页面中嵌入脚本代码的方式运行，这样的例子包括PHP、ASP和JSP。脚本形式的优点是功能强大，缺点是需要花更多的时间理解和格式化Html输出，这带来更多的工作量；服务器页面的优点是最终输出几乎是所见即所得的，同时带来的缺点是代码散布于页面中，难以维护。BTW，这方面，ASP.NET开发平台很好地结合了两者的优点，在支持所见即所得的前提下，提供后台代码分离，极大地提高了开发的效率。

因为脚本方式非常适合于解释请求消息，服务器页面非常适合于格式化应答消息，所以，应该使用脚本语言来解释请求消息，用服务器页面来格式化应答消息。这种用法的分离事实上是一个老观点，它首次出现在使用模型－视图－控制器的用户界面中。（因为这里的控制器实际上主要是解释和处理用户输入，所以作者更喜欢用“输入控制器”这个术语；当然，控制器还有另外一种理解：处理应用程序流，决定视图应该按照什么次序出现）

在视图方面，可以考虑三种模式：转换视图、模板视图和两步视图。模板视图比较容易理解，就是以设计好的Html页面为模板，在页面中嵌入代码；转换视图最常见的例子是XSLT，由输入控制器挑选合适的XSLT样式表单，然后把它应用在由模型收集的XML上，换句话说，就是根据XSLT将XML运算结果转换为Html页面。转换视图和模板视图都是直接由领域数据生成最终的用户界面，是在一个步骤里完成的，称之为单阶视图。两步视图是将这个过程分为两个阶段：由领域数据产生一个逻辑屏幕，然后再由统一的一个视图产生用户界面。读了好几遍，对两步视图仍然不能很好地理解，主要是找不到现实中的具体应用，两步视图有些什么具体（不是理论）应用呢？希望哪位朋友能够帮忙解释一下。关于两步视图，在此摘录一段书中的原文：

如果Web应用程序提供的服务是由多种前端用户来使用，那么运用两步视图将更加得心应手。例如，多家航空公司后台使用的是相同的基本订票系统。在逻辑屏幕的限制下，每个前端由于使用不同的第二阶段，可以得到不同的外观视图。类似的，还可以使用两步视图来处理不同的输出设备，例如，可以用不同的第二阶段区分Web浏览器或掌上电脑。再有，在两个用户界面之间共享公共的逻辑屏幕也是很有限的，当这两个用户界面差异非常大时，比如在浏览器界面和手机屏幕之间，这种共享基本上不可能。

http://happyprogram.cnblogs.com/archive/2005/07/16/194068.html

引言
n 构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。我们只有在不断的学习中进步，从成功经验中学习，从失败教训中学习，才有望克服这些困难。

n 很多人都试图给“架构”下定义，而这些定义本身却很难统一。能够统一的内容有两点：一点是“最高层次的系统分解”；另一点是“系统中不易改变的决定”。

n 全书实际上就是关于如何将企业应用组织成不同的层次，以及这些层次之间如何协同工作。大多数重要的企业应用都是按照某种形式的层次分层设计的；当然，在某些情况下，别的设计方式也有它们自己的价值，本书中我们将不会讨论这些方式，而把注意力集中在层次方式上，因为它是应用最广的设计方式。

n 我的工作主要是关于企业应用的。企业应用一般都涉及到持久化数据……企业应用一般都涉及到大量数据……企业应用一般还涉及到很多人同时访问数据……企业应用还涉及到大量操作数据的用户界面屏幕……通常需要与散布在企业周围的其他企业应用集成。

n 关于业务逻辑：我认为“业务逻辑”这个词很滑稽，因为很难找出什么东西比“业务逻辑”更加没有逻辑。……现实业务中成千上万的“一次性特殊情况”最终导致了复杂的业务“无逻辑”，使得商业软件的开发那么困难。

n 关于性能的一些概念：
响应时间是系统完成一次外部请求处理所需的时间；
响应性不同于请求处理，它是系统响应请求的速度有多块（比如在执行后台任务时显示一个进度条就能够提高用户界面的响应性）；
等待时间是获得系统任何形式响应的最小时间（主要体现在远程调用的网络延迟）；
吞吐率是给定时间内能够处理多大的请求量；
性能或者指吞吐率，或者指响应时间，由用户自己决定；
负载是关于系统当前负荷的表述；
负载敏感度是指响应时间随负载变化的程度；
效率是性能除以资源；
系统的容量是指最大有效负载或吞吐率的指标；
可伸缩性度量的是向系统中增加资源（通常是硬件）对系统性能的影响（垂直可伸缩性一般指增加服务器，水平可伸缩性一般指提高单个服务器的性能）。

当构建企业应用系统时，关注硬件的可伸缩性往往比关注容量或效率更重要（购买新硬件往往比费劲地提高软件性能来得更便宜）。

全书分为两大部分：第一部分“表述”，从第一章到第八章，对全书涉及到的内容进行简要的介绍；第二部分“模式”，从第九章到第十八章，详细讲解各种具体的模式，包括运行机制、使用时机以及示例。

第一章 分层
在分解复杂的软件系统时，软件设计者用得最多的技术之一就是分层。在计算机本身的架构中，可以看到，到处都有分层的例子。

将系统按照层次分解有许多重要的好处：

n 在无需过多了解其他层次的基础上，仍然可以将某一层作为一个有机整体来理解和使用。

n 可以在保持接口不变的前提下替换某层的实现，而不影响使用它的其他层。

n 可以将层次间的依赖降到最低。

n 分层有利于标准化工作。

n 一旦构建好了某一层次，就可以用它为很多服务提供服务。

但分层也有自己的缺陷：层次并不能封装所有的东西；过多的层次会影响性能等。

本书主要对三个基本层次的架构展开讨论：表现层、领域层（业务层）和数据源层。分层架构中最困难的问题是决定建立哪些层次以及每一层的职责是什么。一种不太正规的测试办法是：假想向系统中增加一个完全不同的新层，例如为WEB应用增加一个命令行界面层；如果在这个过程中，发现需要重复实现某些功能，则说明可能有一些应该在领域层实现的逻辑，现在在表现层实现了。类似的，你也可以假想一下，将后台数据库更换成XML文件格式，看看情况又会如何？

BTW，在讨论具体的层次之前，个人觉得，要构建架构良好、健壮的系统，分层的思想是必不可少的，但现实中由于种种原因（包括客观原因和主观原因：比如项目规模、开发人员能力等等），往往并不能够做到纯粹的分层架构，这就得根据实际情况稍微变通，以取得整体上最优的方案。

这一章中，作者给出了一个怎样确定分层边界的方法，该方法虽然简单，却很有效。

第二章 组织领域逻辑
由于领域层介于表现层和数据源层的中间，因此确定其边界是最困难的，也面临更多的挑战，我想，这也是作者把这一层单独作为一章来介绍的原因。

领域逻辑的组织可以分为三种主要的模式：事务脚本、领域模型以及表模块。

事务脚本通俗的说，就是面向过程的模式，将各种业务通过一个个的子程序来实现，这些子程序既负责获取用户输入，也负责将操作结果保存到数据库中；领域模型通俗的说，就是面向对象的模式，通过各种业务对象的相互作用来完成业务，每个对象都明确承担一部分工作；表模块和领域模型很相似，不同的是领域模型中的对象对应的是数据库中的一条记录，而表模块中的对象对应的是数据库中的整张表。

三种模式各有优缺点。事务脚本比较容易理解，但系统越复杂它就越难以维护；领域模型非常规范，但要纯粹的实现它，需要面临的主要问题是对象和关系数据库之间的映射问题；表模块介于两者之间，很多开发平台对表模块和基于记录集的编程都有非常好的支持，因此，它往往是一个不错的折中选择。

第三章 映射到关系数据库
这一章要讨论的问题是领域层如何访问数据库的问题。作者给出了几种模式：行数据入口、表数据入口、活动记录、数据映射器。

行数据入口模式是指对数据库中的每一条记录建立一个对象与其相对应，该对象提供该数据的属性和操作接口；表数据入口是指对数据库中的每一个表建立一个对象（一般是记录集）与其相对应，该对象提供该表的操作接口；通过在行数据入口模式的对象中添加业务逻辑，就形成了活动记录模式，该对象既负责数据库基本操作，又提供业务接口；当领域逻辑越来越复杂时，活动记录中的对象将难以直接和数据库表一一对应，这时，就可以将这些对象分为业务对象和数据映射器对象来解决这个问题，其中数据映射器对象仍保持和数据库的一一对应，而业务对象使用数据映射器对象提供的接口来实现数据操作，这就形成了数据映射器模式。

根据不严格的观察，关系数据库的映射开销大概是程序开发总开销的1/3左右，而且还会一直持续到维护阶段。在发展过程中，出现了面向对象数据库，试图解决这些问题，然而由于其成熟程度以及出于规避风险的原因，大多数项目并不使用它。另一方面，O/R映射工具却为这个问题提供了一个较好的解决途径，获得O/R映射工具的途径可以是购买或者自己开发，我想很多开发人员都在做这个工作。

关于读取数据的一些讨论：作者把读取数据的方法看作一个查找器，那么在什么地方放置查找器呢？讨论后得出一个通用的参考方式是：查找器可以和表数据入口对象放在一起，如果是行数据入口，则应该单独创建查找器对象。

当人们谈到对象－关系映射的时候，他们多半说的是结构映射模式，在内存对象与数据库表的映射中会用到他们。作者对关系的映射、继承的映射、数据库连接池等问题进行了一些一般性的讨论，这里就不多讲了。

优化分为系统级优化及应用级优化

系统级优化包括：
1. 操作系统优化
2. web server优化
3. 数据库优化
4. 硬件优化

应用级优化包括
1. 代码逻辑优化，比如用汇编、编译时使用优化选项、减少循环次数、更换算法等等
2. 架构优化，比如将同步操作改为异步操作、用多进程、多线程代替单线程、读写逻辑分离等等

待续…