.NET Web 入门系列之架构理念
一、Web项目最简构成
1.什么是Web项目
所谓Web项目，就是一个可通过网络访问的，以浏览器为呈现载体的，可响应用户操作交互而呈现数据信息的可视化程序。
如下图所示：
图中的PC端即B/S架构中所谓的浏览器端，用于呈现Web页面，用户在浏览器中输入网址，经DNS解析完成后，即向解析所得IP地址对应的Server端发送http请求，Server端接收到请求后根据信息服务管理器（IIS）的部署，返回相对应的页面及加载所需的文件，若请求参数有误或无访问权限则返回错误页。
用户在Web页面上的鼠标点击、文本输入等输入操作，一般根据Web页面中的元素定义或javascript脚本自行响应，若需服务端提供数据处理等特殊的处理方式，则通过Ajax方式与Server端进行通讯及数据传输。
数据源多使用数据库，也有诸如.xls, .txt等本地文件，各自对应不同的访问方式。视业务逻辑需求，自行决定是否使用及使用何种数据源。
以上就是一个Web项目的最基本的构成。
2.涉及知识结构
二、从迭代的角度看为什么要分层
1.迭代
我们开发一个产品，如果不太复杂，会采用瀑布模型，简单的说就是先定义需求，然后构建框架，然后写代码，然后测试，最后发布一个产品。但这样的方式有明显的缺点，假如我们对用户的需求判断的不是很准确时，当你把产品拿给客户看，客户往往会大吃一惊，这就是我要的东西吗？
而此时的修改成本是和风险往往是巨大的，因此为了尽可能规避这种风险，降低修改成本，在项目实践中通常会采用迭代的方式完成开发。即在开发过程中不断与客户进行交流反馈，从而获取客户对已完成部分的修改意见，以较少的时间和人力成本进行修正，同时继续进行未完成的开发。这种通过不断反馈、不断修正以达到客户要求的开发方式，就是我们所说的迭代开发。
PS: 另一种常见的情形是客户的部分需求中途发生变更或迟迟不能确定，此时也需要开发人员做好面临修改、返工的心理准备。
2.分层
微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
- 数据访问层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务．
- 业务逻辑层：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
- 表示层：以aspx为例，提供数据展示与交互操作的页面，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。
3.迭代对分层的需求
面向对象编程与面向对象编程最本质的区别，大概就在于面向对象编程中的封装与引用。这大大降低了代码量，并为继承等特性提供了基础。然而在很多初学者进行开发时，往往忘记了类的定义——对具有共同特征的事物的高度抽象，于是定义混乱，引用错纵复杂，代码冗余等屡见不鲜。例如初学者可能在每个需要执行sql语句的代码段中，定义一次sqlConnection，配置一次连接字符串，然后定义sqlCommand，于是一个项目中有多处相似的代码段，造成代码冗余，若数据库连接字符串需要修改，需要连续修改多处。
其实较好的处理方式，是将对数据库所有的操作都封装在一个Class中，以网上流传较多的sqlHelper.cs为例，内部定义增、删、查、改等对数据库的访问方法，构造方法中定义sqlConnection并执行其Open方法，将数据库连接字符串定义在config文件中，这样在各个需要执行sql语句的代码段中，只需要实例化一个sqlHelper类，然后调用相应的访问方法即可，而连接字符串需要修改时，只需要将config文件中对字符串的定义改掉，其余部分的代码都不需要调整。
由此，在代码实现过程中，将对数据库访问、修改相关的方法，统归在一个项目中，将按业务逻辑对数据进行处理的方法归在另一个项目中，表示层只包含对交互操作和对数据展示的定义，以尽可能减少某一层的修改所带来的额外工作量，不仅降低了需求变更的风险成本，也正好遵循了“低耦合高内聚”的软件设计思想。
以上即为从迭代角度，应该采取分层架构的目的——减少修改所需要的成本。
