《.NET应用架构设计：原则、模式与实践》新书博客--试读-1.3-1.4

1.3  架构设计中的重要概念

接下来的这一节主要提及与架构有关的一些概念。

 

1.3.1  Tier和Layer

 

    有些做开发的朋友容易把Tier和Layer混淆，或者认为两者是一样的。其实这两个概念并不相同，最简单的解释就是：Layer往往是指系统的逻辑结构，而Tier则是指系统的物理部署结构，不同的Layer可以在同一Tier上；不同的Tier上面可以有相同的Layer。这两个概念一般在分层的系统中提及最多。

 

    下面以一个分层的ASP.NET SNS项目为例来说明，此项目的系统可能会分为界面层、界面控制层、服务层、业务层、数据访问层、数据存储访问层。这些就是逻辑层，也就是所谓的“Layer”。

 

 

    在项目初期可能考虑到经济等某些因素，把除了界面层之外的其他逻辑层都部署在一台服务器上面，界面层就是用户在浏览器中看到的HTML页面。现在系统就是由6个逻辑层（Layer）组成，也是由2个物理层（Tier）组成（如图1-8所示），不同的Layer可以在同一Tier上。

 

图1-8  6个逻辑层2个物理层

 

    随着系统的使用和用户的增长，系统逻辑部分还是和之前一样，但是物理部署的层次就变化了，它采用了服务器群集的方法来达到负载均衡。那么就出现了不同的Tier上面可以有相同的Layer的情况，如图1-9所示。

 

图1-9  Web Farm

1.3.2  架构与框架

 

    到现在为止所有的讨论都集中在架构和设计上面。尽管这些都非常重要，但是并非每次创建软件项目都要经历这个过程。我们可能会把这架构和设计固化在可重用的代码中，从而能够在创建其他新的项目时重复使用。那么我们此时需要的就是一个“框架”：它以编码的方式实现了架构和设计，以便于提高重用性和生产效率。

 

    一般的开发过程会从收集和分析需求开始，然后是架构讨论和决策，接下来就是设计。首先是用低级别的概念设计支持架构，然后是真正对最终用户有用的业务概念设计。设计完成之后，开发者通常会花费相当长的时间来实现低级别的代码以支持稍后的业务代码的编写。

 

    所有对架构的讨论、决策、设计，以及编码都是非常重要的。但是不幸的是，这对于编写业务逻辑，提供业务功能的最终目标没有直接的意义。低级别的支持技术只能为创建实际的业务应用提供帮助，很多时候，我们只要实现一次，然后就可以在多个项目中重用它。

 

    在软件世界中，将架构和设计写到框架里面是最容易降低开销、提高重用性的方法。所以可以把框架看成是架构和设计的一种积累，经过多个项目的开发，不断地修改和完善框架，最后使得整个框架能够在性能、伸缩性、安全性等方面满足需求。

 

1.3.3  架构与模式

 

    每次谈及架构，所冒出的第一反应就是：架构就是设计模式，架构就是企业架构模式等诸如之类。相信通过上面章节的讲述，大家已经清楚了架构和模式的关系（基本没有很明确的关系，更加不存在等同的效应）。模式是经验的重用，模式对软件开发中出现的一些问题给出了比较好的解决方案。模式的决定和使用，常常是设计阶段考虑的问题，当然在架构创建的时候它是可以给一些问题以指导的，在这些指导中可能就包含了可以采用什么模式达到什么目的等。在架构和设计中，有时候采用了合适的模式，便可以快速地解决某些问题，但是两者绝对不是等同的关系，也不是多多益善的关系。

更多的话题，将在后续章节中讲述！

 

1.4  本章小结

 

    这一章定义并解释了本书中使用的核心概念：架构、架构师和架构设计。这一章也讨论了软件开发流程采用以架构为中心的方式所带来的好处。然而，关于架构设计仍然有许多问题没有解决。例如，实际上架构师在软件开发项目中做什么、架构师产出什么、架构师角色如何与项目的其他角色发生联系等，这些问题将在后续章节中介绍。

 

    当当网：

    京东地址：

    卓越地址：