网络运维简介

一、前言

大家好，接近一年的时间没有怎么书写博客了，一方面是工作上比较忙，同时生活上也步入正轨，事情比较繁多，目前总算是趋于稳定，可以有时间来完善以前没有写完的系列，也算是对自己这段时间工作和生活上总结，同时也加深下自己对架构和

设计方面的理解，由于本人的写作水平有限，所以在书写的深度和书写的格式上还有很多的缺点，还希望大家多多指出。

二、开篇

本篇我们将针对系统架构中的分层进行讲述，分析不同分层模式的优缺点及应用的场景，当然我们会结合一些案例来介绍这些分层，通过案例来证明各种分层的好处与优缺点，本篇作为开篇主要是介绍这个分层系列中会讲述到的几种分层模式实践，

由于很多分层模式也是自己在工作过程中总结和经验积累下来的，可能存在个人理解或用法上错误之处，还请大家指出，我予以及时更正。

三、内容提要

1、前言

2、开篇

3、本文提纲

4、分层模式

4.1、分层架构介绍

4.1、后端分层多层

4.1.1、普通三层架构

4.1.2、多层架构

4.2、前端分层模式

4.2.1、MVC模式

4.2.2、MVP模式

4.2.3、MVVM模式

5、结束语

6、系列进度

7、下篇预告

四、分层模式

4.1、分层架构介绍

架构首先是分为不同层次的和不同视图的，例如架构有五种视图：逻辑视图、物理视图、数据视图、运行视图、开发视图。我们今天不讲解这几个不同的视图，而是讲解分层对于软件设计的意义及关注点，之前我也发过一片单机软件架构的文章，文

章中提到了一个软件从简单到复杂的全过程，而软件架构也是一个迭代的过程，是一个循序渐进，不断完善的过程。

我们今天交流的主要是逻辑纬度的分层，关于物理视图的分层，本篇先不讲解，因为那块更复杂，同时也更重要，对于大型的互联网软件或大型的互联网网站，更关注的是物理架构方面的设计。下面我们就来针对当前的一些分层模式来进行讲解，并

且进行简要的分析和应用场景介绍。

4.2、后端分层架构

一、普通三层架构

三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。

三层架构图

对于传统的三层架构图，可能因为大家在实际的场景中，因为大家对这些分层运用的不同，会出现适应的场景的不同，而且有很多的大型软件或项目，都是采用三层架构，我们可以通过引入一些开源的组件或自定义组件来构建非常灵活或扩展性很强

的分层结构，虽然是3层架构，但是却可以满足大部分的场景。

A、场景：

最原始的三层结构可能如下：

ThreeArchitecture.Entities：实体定义层，该层主要是完成各分层间数据传递并且最终通过该实体实现DAL层与数据库交互的数据传输。

ThreeArchitecture.DAL：数据访问层，通过调用实体层，通过https://www.360docs.net/doc/3713198638.html,编程，实现数据持久化，例如可以支持多种数据库，sqlserver、oracle、mysql、sqlite.

ThreeArchitecture.BLL：业务逻辑层，通过调用实体层、数据访问层，实现整个业务系统的核心功能，完成系统业务的处理。

ThreeArchitecture.UI：用户界面交互层，用户通过该用户界面与业务系统进行交互，完成业务逻辑操作与交互。

根据上面的解决方案的分层及组织，下面针对以下几个场景来分析，分析三层架构中遇到的问题，应该如何解决这些问题。

1）、如果需要实现多数据库支持。我想业务系统能够从sqlserver向oracle数据迁移，或反之。

这样在现有的项目结构方式，就无法满足，但是我们可以增加新的接口层来实现这个要求。

例如可以通过如下项目方式来组织：

修改原有的项目划分结构，加入DAL.Interface层次。定义数据访问接口，通过不同的数据访问实现，然后通过数据访问层工厂，来构建不同的数据库访问实例。

这块具体的代码我就不贴出了，应该比较简单。

同时原来的ThreeArchitecture.BLL调用的不是直接调用数据库访问层实现，而是调用数据访问层接口。不依赖于具体的实现，而是依赖接口，这样可以实现解耦，提供了很强的扩展性。

2）、如果我要求业务逻辑层实现也不一定固定，例如在医疗行业的话，每个医院的业务系统或业务流程都不相同，那么假设我们希望沟通统一的UI界面，而不是随着业务逻辑的改变而修改UI，那么我们就需要进行如下的设计：

项目的结构方式类似上面的DAL层的变化。

在原来的基础上改进：

ThreeArchitecture.BLL.Interface：定义业务逻辑接口，主要目标是隔离UI与业务逻辑实现间的依赖关系，将实现代码调用修改为接口调用方式。ThreeArchitecture.BLL.A：A场景下的实现，A的业务逻辑。

ThreeArchitecture.BLL.B：B场景下的实现，B的业务逻辑。

3）、纵向和横向扩展性需求场景，例如场景变化灵活性较高时，工厂模式无法很好应对，需要维护大量的工厂代码。

可以采用开源的相关组件，来实现解耦及隔离，例如数据访问层可以采用Nhibernate或Entityframework来实现，关于Nhibernate的文章，园子里面已经有很多的文章介绍了，我就不介绍了，

引入Nhibernate以后，项目的结构，回到如下模式

ThreeArchitecture.DAL.Nhibernate：NHibernate实现数据访问层接口，Nhibernate支持目录主流的大部分数据库，所以不需要按照1）中的方案去做，只需要实现一次即可。

ThreeArchitecture.DAL.EntityFramework：EntityFramework实现数据访问层接口，EntityFramework支持Oracle,SQLServer，其他的数据库支持的不太好。

在上面的场景中，例如在A场景下，我希望使用A业务层、B场景下使用B实现，而且，不希望系统中维护大量的工厂代码，那么我们就请出来当前架构或框架设计的核心组件IOC

IOC：控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是当前主流框架的核心。控制反转还有一个名字叫做依赖注入（Dependency Injection）。简称DI。

采用了IOC以后，接口和实现就可以通过配置的方式来动态的设置，而且调用的方式也变得更简单，不需要其他复杂的代码设定，目前市面上的IOC容器很多，我了解的主要是以下几种：

Unity：微软的轻量级IOC容器。提供了比较强的注册和动态查找机制，同时提供了强大的AOP，几乎无所不在。

Autofac：Autofac是一款IOC框架，比较于其他的IOC框架，如https://www.360docs.net/doc/3713198638.html,，Unity，Castle等等所包含的，它很轻量级性能上也是很高的

https://www.360docs.net/doc/3713198638.html,：参考java的sprint 框架的.net平台下的实现，比较强大。

Castle：Castle是针对.NET平台下的一个非常优秀的开源项目，从数据访问框架ORM到依赖注入容器，再到WEB层的MVC框架、AOP，基本包括了整个开发过程中的所有东西，为我们快速的构建企业级的应用程序提供了很好的服务

Ninject：是一个快如闪电、超轻量级的基于.Net平台的依赖注入框架。它能够帮助你把应用程序分离成一个个松耦合、高内聚的模块，然后用一种灵活的方式组装起来。通过使用Ninject配套你的软件架构，那么代码将会变得更加容易编写、重用性强、

易于测试和修改。

关于上面介绍的部分IOC容器的用法整体上来说都差不多，具体的大家可以网上搜索下，案例和demo比较多。

二、多层架构

上面介绍了普通的三层架构，多层架构顾名思义就是在三层架构之上，通过扩展及应用场景的挖掘，衍生出来的适应不同场景的架构模式，下面我主要是来介绍以下几种多层架构模式

A、服务层模式

在上面介绍的3层架构模式中，存在一个缺陷，如果我们构建的软件或系统支持分布式或者需要对外提供服务的时候，这个场景就无法满足了，所以这个时候服务层就出现了，就是在BLL层的基础上进行包装，包装成可以对外提供调用的分布式服务。

经过改造后的项目结构如下：

在项目中加入了03.解决方案文件夹，同时添加项目ThreeArchitecture.Service项目。

ThreeArchitecture.Service:主要是提供几个作用：1、将业务逻辑层进行封装，对外提供业务服务调用。2、通过外观模式，屏蔽业务逻辑内部方法。3、降低业务逻辑层与UI层的依赖，业务逻辑接口或实现的变化不会影像UI层。4、降低UI层调用的请求次

数及数据往返。

在上面的结构中，我们说了Service层次的作用，目前还少加入了一层，DTO(数据传输对象层)，该层负责屏蔽后端的实体层，将UI层需要的数据进行重新的定义和封装，在实际的业务场景下，后端实现或存储的数据远比用户需要的数据要庞大和负责，所

以前端需要的数据相对来说要么是组合的，要么是抽取的，不是完整的，因为我们在设计数据存储格式上都会有一些额外的设计和考虑。

加入了ThreeArchitecture.DTO层后，前端的UI层，只是知道DTO的存在，同时前端需要的数据都在一个Dto中，这样，每次调用服务层的时候，只需要调用一次就可以完成所有的业务逻辑操作，而不是原来的直接调用业务逻辑层那样的，需要调用多

次，对于分布式场景下，减少服务调用的次数，尤其重要。

B、DDD架构模式：

Presentation Layer: 负责与客户端进行交互

Application Layer: 负责协调领域层之间的交互

Domain Layer: 软件的核心，所有相关的Domain information都在这，可以看成是Business Logic Layer，但不完全是Infrastructure Layer: 負責各層之間的交互溝通、資料存取、安全性管理及通用Library

更常见的是如下层次

我们建议的方式如下：

Repository层使用ORM映射或SQL命令等方式把持久化数据转化为领域对象，然后根据业务逻辑设计对应领域层服务Domain Service 。接着应用层进行操作上的协调，利用Repository、领域模型、领域层服务Domain Service 完成业务需要，再通过数

据转换器把领域对象Domain Object转化为数据传输对象DTO。最后，利用远程通讯技术把应用层的服务（Application Service）对外开放。

注意留意的是SOA系统中，UI表现层与Application Service应用层服务是实现分离的，表现层可以同时调用多方的远程服务来完成工作。

在上面的架构中还可以加入领域事件、查询接口、分布式服务层，来灵活运用和组合，来解决项目中适应场景的不同。

4.3、前端分层架构

A、MVC架构模式

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑和数据显示分离的方法组织代码，将业务逻辑被聚集到一个部件里面，在界面和用户围绕数据的交互能被改进和个性化

定制的同时而不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

目前在主流的框架中都支持该模式，例如构建winform程序中可以通过MVC模式来分离界面层中的控件与后端服务间的交互。降低耦合及依赖。

web上通过https://www.360docs.net/doc/3713198638.html, MVC框架来实现前端页面及后端控制器之间的隔离。

视图

视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Adobe Flash和像XHTML，XML/XSL,WML

等一些标识语言和Web services.

MVC好处是它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。

模型

模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器

控制器接受用户的输入并调用模型和视图去完成用户的需求，所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数

据。

https://www.360docs.net/doc/3713198638.html, MVC

关于具体的代码，大家可以尝试新建一个MVC的应用程序，微软提供的默认的MVC的代码模版中就有相关的示例代码，具体的我就不介绍了。Winform的MVC模式

winform的MVC模式，主要是通过事件的方式来实现。

B、MVP架构模式

MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间

的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过Controller。

在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于Vie

w，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

1、View和Model完全解耦，两者不发生直接关联，通过Presenter进行通信。

2、Presenter并不是与具体的View耦合，而是和一个抽象的View Interface耦合，View Interface相当于一个契约，抽象出了对应View应实现的方法。只要实现了这个接口，任何View都可以与指定Presenter兼容，从而实现了P Logic的复用性和视图的无缝替换。

3、View在MVP里应该是一个“极瘦”的概念，最多也只能包含维护自身状态的逻辑，而其它逻辑都应实现在Presenter中。

总的来说，使用MVP模式可以得到以下两个收益：

1、将UI和P Logic两个关注点分离，得到更干净和单一的代码结构。

2、实现了P Logic的复用以及View的无缝替换。

展示器层作为核心的控制，实现view和model之间的完全解耦。关于该架构设计的具体demo 后面来介绍

C、MVVM架构模式

MVVM是Model-View-ViewModel的简写。

微软的WPF带来了新的技术体验，如Sliverlight、音频、视频、3D、动画……，这导致了软件UI层更加细节化、可定制化。同时，在技术层面，WPF也带来了诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、C

ontrolTemplate等新特性。MVVM（Model-View-ViewModel）框架的由来便是MVP（Model-View-Presenter）模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性揉合进去，以应对客户日

益复杂的需求变化。

MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model），有几大优点

1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model 变化的时候View也可以不变。

2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。

3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。

4. 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。