网络运维简介.docxVIP

一、前言 大家好，接近一年的时间没有怎么书写博客了，一方面是工作上比较忙，同时生活上也步入正轨，事情比较繁多，目前总算是趋于稳定，可以有时间来完善以前没有写完的系列，也算是对自己这段时间工作和生活上总结，同时也加深下自己对架构和设计方面的理解，由于本人的写作水平有限，所以在书写的深度和书写的格式上还有很多的缺点，还希望大家多多指出。二、开篇 本篇我们将针对系统架构中的分层进行讲述，分析不同分层模式的优缺点及应用的场景，当然我们会结合一些案例来介绍这些分层，通过案例来证明各种分层的好处与优缺点，本篇作为开篇主要是介绍这个分层系列中会讲述到的几种分层模式实践，由于很多分层模式也是自己在工作过程中总结和经验积累下来的，可能存在个人理解或用法上错误之处，还请大家指出，我予以及时更正。三、内容提要 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：数据访问层，通过调用实体层，通过A编程，实现数据持久化，例如可以支持多种数据库，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