第2章 创建基础框架

第2章创建基础框架既然你已经向客户承诺创建一个很酷的Web网站来提升客户商店的实力，现在该停止庆贺，开始考虑如何实现对客户所做的承诺了。

通常，当你书写技术需求时，会发现所有的事情都比预期的要复杂一些。

为了确保该项目获得成功，必须采取一种巧妙的方法来实现已签订的合同。

你希望项目的开发平稳且快速，但最终的目标还是使客户对你的工作感到满意。

因此针对提高访问量的目标，你可能计划创建一个漂亮、功能完备、反应迅速的网站，以给用户愉快的购物体验。

用户的要求总是很高，但这对于当今的电子商务网站而言是很正常的。

为了使成功的机会最大化，我们将尝试分析和预期尽可能多的技术需求，并以最简单的方式支持变更和新增功能来实现解决方案。

本章中，你的目标是：●从技术视角来分析该项目；●为你的应用分析并选择一个架构；●决定使用哪项技术、哪种编程语言和工具；●探讨命名和编码规范；2.1针对发展设计对于Web应用系统而言，"设计"可以用来表示很多事情。

最普遍的说法是表示Web网站的视觉效果和用户界面（UI）设计。

这个方面是十分关键的，必须重视它，能给访问者留下最直观印象的是网站的视觉效果以及使用的简便性。

访问者们不会太关心网站使用了什么技术，背后有什么技巧，或者Web 服务器在什么操作系统上运行。

如果网站难以使用就会很容易被用户遗忘，不管是用什么样的高科技来创建的。

然而，这个真理却让许多经验不足的程序员低估了网站实现中不可见部分（包括代码、数据库等）的重要性。

网站的视觉效果只是给访问者的第一印象，网站的功能才是使他们再次访问的秘诀。

基于确定的最初需求，能够很快地实现网站，但如果架构设计不合理，更新网站可能会很困难。

无论是什么项目，不管规模多大，有些准备工作在开始编码之前必须完成。

不管做了多少规划和设计工作，总会发生意外的情况，查找隐藏的错误、满足新的需求以及应付变化的规则，而这些问题似乎总会和最后的期限作对。

即使没有这些意外因素，网站设计者也经常在项目完成并部署很长时间之后，被要求修改或新增功能。

这对于BalloonShop而言也是一样，我们在第1章已经讨论了要分成三个独立阶段开发它。

你将学会如何更好地创建该Web网站，避免在功能扩展和更新时崩溃。

由于这是一本编程方面的书，因此并不解决电子商务的其他重要方面，诸如UI的设计、营销技术以及法律问题。

你需要其他素材来解决这些问题。

在本书中，将集中关注于使该网站正常工作的代码构建上。

"代码设计"这个词组可以包含不同的含义。

例如，需要简单地探讨一下命名规范等。

不过最重要的方面是在编写代码之前关注其架构。

架构指的是一种方法，它将许多实现简单功能（例如，商品搜索功能）的代码分解到较少的、互相连接的组件中。

尽管在单个组件中尽可能快速和简单地实现要完成的功能，会更加容易；但创建多个通过协作来实现预期结果的组件将会使你获得更长效的好处。

在考虑架构本身前，必须确定想从这个架构中获得什么。

以最小的努力满足长远需求除了需要实现执行速度很快的Web网站之外，在第1章中所提到的每个开发阶段都将引入要满足的新需求。

每当开始一个新的阶段时，你都希望重用现有解决方案的大部分内容。

如果仅是因为添加一个新的功能而重新设计网站（不仅包括视觉效果部分，还包括代码），那是很低效的。

可以事先计划好重用解决方案，以使得可以简单地插入添加的新功能，也就不会为每个新的变化而头大了。

在构建Web网站时，实现基于插件式组件的弹性架构，就能够将一些功能编码为独立的组件，例如购物车、门类列表或商品搜索等，然后将它们插入到现有应用程序中。

达到较高的弹性水平，是应用系统架构设计的目标之一，本章将展示如何实现它们。

你会发现弹性水平是与设计和实现所花费的时间成正比的，因此必须寻求一个折中，既不使代码过于复杂又能获得最大的利益。

在线应用系统的另一个主要的需求是可伸缩的架构。

伸缩性的定义是只需通过增加资源，就能够线性地提高服务能力。

换句话说，在一个可伸缩的系统中，即使客户的数量不断增加（理想状态），客户请求数和处理这些请求所需的硬件资源数之间的比率（比例）也应是常数。

而不可伸缩的系统，不管提供多少硬件，都无法满足客户数量的增长所带来的需求。

由于我们对顾客的数量很有信心，因此必须确保网站能够向大规模的客户提供它的功能，并且不会抛出异常或执行速度缓慢。

可靠性也是电子商务应用的一个很重要的方面。

有了异常处理策略和强大的关系数据库的帮助，可以确保数据的完整性，而非致命错误也不会使网站被击垮。

2.2使用三层架构通常，架构是指将应用系统的每个功能部分分解到独立的组件中，并将各种组件划分到各个逻辑层中。

现在三层架构越来越流行，这是因为它回答了迄今为止争论的所有问题。

它将应用系统的功能单元分到三个逻辑层中：●表示层；●业务层；●数据层。

表示层包括网站的UI元素，并且包含管理访问者和客户业务之间交互的所有程序逻辑。

该层使整个网站充满活性，而且这一层的设计方法对网站的成功至关重要。

由于你的应用系统是Web网站，因此表示层将由动态Web页面组成。

业务层（也称为中间层）接收来自表示层的请求，并基于其包含的业务逻辑，向表示层返回一个结果。

表示层中所发生的事件，绝大部分都会调用业务层（除了那些表示层自己就能够处理的事件，诸如简单的数据输入验证等）。

例如，如果访问者进行一次商品搜索，那么表示层将请求业务层，说："请将与该搜索条件相匹配的商品发给我。

"绝大多数情况下，业务层都需要调用数据层的信息，以响应表示层的请求。

数据层（有时也称为数据库层）负责保存应用系统的数据，并当有请求时把它们发送给业务层。

BalloonShop电子商务网站就需要保存与商品（包括其门类和分类）、用户、购物车等相关的数据。

几乎所有的客户请求最终都将查询数据层的信息（除非在业务层或表示层的缓存中已经包含了先前查询的数据），因此有必要拥有一个快速的数据库系统。

在第3章和第4章中，你将学到如何针对性能优化来设计数据库。

这些层是纯逻辑的，并不约束每个层的物理位置，可以自由地部署应用程序。

换句话说，可以将所有的层都部署在一个服务器上，也可以将每个层部署在不同的机器上。

如果应用程序允许的话，甚至可以将一个层中的组件部署在多台机器上。

第20~22章将说明如何使用XML Web服务整合其他网站的功能。

XML Web服务可以集成多台服务器上的功能，而且无需使用大量的自定义代码。

在三层架构模型中，有一个很重要的约束是在层之间的数据传递必须遵从特定的顺序。

表示层只允许访问业务层，而永远不能直接访问数据层。

业务层就像中间的"大脑"，负责与其他层通信，处理和协调所有信息流。

如果表示层直接与数据层交互，将打破三层架构的编程规则。

这一规则乍看起来像是一种限制，但当你使用这一架构时，你需要始终服从这一规则，以从中获益。

严格遵从三层架构可以确保网站易于更新、修改，同时还添加了一层控制，用来限定谁或什么能够访问你的数据。

该功能现在看起来是不必要的；不过，如果需要改变网站功能或逻辑，那么你将能够从中获得更多收益。

图2-1中表现的是三层架构的应用系统中数据的传递。

1. 简单的场景如果仔细观察一个简单的例子，那么可以更容易地理解层之间数据的传递。

结合本项目的实际情况，我们将分析一个在BalloonShop中实际发生的场景。

这是三层架构应用程序中的典型场景。

和大多数电子商务站点相似，BalloonShop中也有购物车，我们将在本书的后面章节中详细说明。

现在，只需知道网站访问者将通过点击一个Add to Cart（添加到购物车）按钮，将商品添加到购物车中。

图2-2展示了点击该按钮后应用系统中信息流的情况。

第1步，用户点击针对某个特定商品的Add to Cart按钮。

第2步，表示层（包含该按钮的层）将把该请求转发给业务层，"嗨，我想将这个商品添加到访问者的购物车中！"。

第3步，业务层收到该请求后，就知道用户想将一个特定的商品添加到购物车，其处理的过程是，告诉数据层用所选的商品来更新访问者的购物车。

要调用数据层的原因是，它存储并管理着整个Web站点的数据，包括用户的购物车信息。

第4步，数据层将更新数据库，并最终向业务层返回一个成功代码。

第5步，业务层将处理这个返回代码以及数据层在更新数据库时可能遇到的任何错误，然后将结果输出到表示层中。

第6步，表示层生成并更新购物车视图。

第7步，其执行结果将封装为HTML Web页面，然后在网站访问者的Web浏览器上就将看到更新后的购物车。

注意，在这个简单的例子中，业务层所负责的处理并不太多，而且其业务逻辑也不是很复杂。

不过，如果应用系统出现了新的业务逻辑规则，那么就需要修改业务层。

例如，如果有这样一条业务逻辑，只有当商品库存量大于0时，才能将其添加到购物车中，而调用另一个数据层可以确定该数量。

只有当库存中有某商品时，数据层才会收到更新购物车的请求。

无论如何，表示层都将了解其状态，并用易于理解的方式反馈给访问者。

2. 在数字中蕴藏什么对于相同信息每个层都有不同解释，这是很有趣的。

对于数据层，其存储的数字和信息并没有什么意义，因为它只是保存、管理的引擎，负责查询数字、字符串或其他数据类型，没有什么商品数量或商品名称。

在前面的例子中，表示商品数量的0就数据层（简单的0，一个32位整数）而言就是一个简单的纯数字，并没有什么深刻的含义。

只有业务层读取该数字时，它们才具有意义。

当业务层向数据层查询商品数量时，如果获取的结果是0，业务层将会把其翻译成"嗨，库存中没有该商品！"，最后这个数据还将被表示层封装成一个漂亮的、可视化的表单，例如，写着"对不起，现在不能订购该商品"的标签。

即使你不想禁止顾客将库存中没有的商品添加到购物车中，本例（如图2-3所示）也足以从另一个角度表现出三个层中的每个层都具有不同的目标。

3. 为正确的层赋予正确的业务逻辑由于每个层都包含着自己的业务逻辑，所以很难在各个层之间划出一个清晰的界限。

在前面的场景中，并不是在业务层读取商品的数量，而是根据一个数（是两次数据层调用即数据库调用的结果）来决定该商品是否可用，或许会有一个命名为AddProductIfAvailable的独立数据层方法，此方法只当库存有存货时才将商品添加到购物车中。

在这个场景中，一些逻辑从业务层迁移到了数据层。

在大多数情况下，你可以自由地决定将某个逻辑放在某一层，或者放在某两层。

换句话说，实现三层架构并没有唯一的最佳方法，你必须依据个人偏好或外部约束做出妥协或选择。

有时，即使你知道实现某些东西的正确方法（遵从架构设计），仍然可以打破这些规则以获得更好的性能。