.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文件中对字符串的定义改掉,其余部分的代码都不需要调整。

      由此,在代码实现过程中,将对数据库访问、修改相关的方法,统归在一个项目中,将按业务逻辑对数据进行处理的方法归在另一个项目中,表示层只包含对交互操作和对数据展示的定义,以尽可能减少某一层的修改所带来的额外工作量,不仅降低了需求变更的风险成本,也正好遵循了“低耦合高内聚”的软件设计思想。

      以上即为从迭代角度,应该采取分层架构的目的——减少修改所需要的成本。

原文地址:https://www.cnblogs.com/cleverJoe/p/5784899.html