系統架構師-基礎到企業應用架構-分層[上篇]

時間 2019-11-05

標籤系統架構師基礎企業應用架構分層上篇欄目系統架構简体版

原文原文鏈接

1、前言

你們好，接近一年的時間沒有怎麼書寫博客了，一方面是工做上比較忙，同時生活上也步入正軌，事情比較繁多，目前總算是趨於穩定，能夠有時間來完善之前沒有寫完的系列，也算是對本身這段時間工做和生活上總結，同時也加深下本身對架構和前端

設計方面的理解，因爲本人的寫做水平有限，因此在書寫的深度和書寫的格式上還有不少的缺點，還但願你們多多指出。java

2、開篇

本篇咱們將針對系統架構中的分層進行講述，分析不一樣分層模式的優缺點及應用的場景，固然咱們會結合一些案例來介紹這些分層，經過案例來證實各類分層的好處與優缺點，本篇做爲開篇主要是介紹這個分層系列中會講述到的幾種分層模式實踐，mysql

因爲不少分層模式也是本身在工做過程當中總結和經驗積累下來的，可能存在我的理解或用法上錯誤之處，還請你們指出，我予以及時更正。web

3、內容提要

一、前言sql

二、開篇數據庫

三、本文提綱編程

四、分層模式後端

4.一、分層架構介紹安全

4.一、後端分層多層架構

4.1.一、普通三層架構

4.1.二、多層架構

4.二、前端分層模式

4.2.一、MVC模式

4.2.二、MVP模式

4.2.三、MVVM模式

五、結束語

六、系列進度

七、下篇預告

4、分層模式

4.一、分層架構介紹

架構首先是分爲不一樣層次的和不一樣視圖的，例如架構有五種視圖：邏輯視圖、物理視圖、數據視圖、運行視圖、開發視圖。咱們今天不講解這幾個不一樣的視圖，而是講解分層對於軟件設計的意義及關注點，以前我也發過一片單機軟件架構的文章，文

章中提到了一個軟件從簡單到複雜的全過程，而軟件架構也是一個迭代的過程，是一個按部就班，不斷完善的過程。

咱們今天交流的主要是邏輯緯度的分層，關於物理視圖的分層，本篇先不講解，由於那塊更復雜，同時也更重要，對於大型的互聯網軟件或大型的互聯網網站，更關注的是物理架構方面的設計。下面咱們就來針對當前的一些分層模式來進行講解，並

且進行簡要的分析和應用場景介紹。

4.二、後端分層架構

1、普通三層架構

三層架構(3-tier architecture) 一般意義上的三層架構就是將整個業務應用劃分爲：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。區分層次的目的即爲了「高內聚，低耦合」的思想。

三層架構圖

對於傳統的三層架構圖，可能由於你們在實際的場景中，由於你們對這些分層運用的不一樣，會出現適應的場景的不一樣，並且有不少的大型軟件或項目，都是採用三層架構，咱們能夠經過引入一些開源的組件或自定義組件來構建很是靈活或擴展性很強

的分層結構，雖然是3層架構，可是卻能夠知足大部分的場景。

A、場景：

最原始的三層結構可能以下：

ThreeArchitecture.Entities：實體定義層，該層主要是完成各分層間數據傳遞而且最終經過該實體實現DAL層與數據庫交互的數據傳輸。

ThreeArchitecture.DAL：數據訪問層，經過調用實體層，經過Ado.net編程，實現數據持久化，例如能夠支持多種數據庫，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框架，如Spring.NET，Unity，Castle等等所包含的，它很輕量級性能上也是很高的

Spring.NET：參考java的sprint 框架的.net平臺下的實現，比較強大。

Castle：Castle是針對.NET平臺下的一個很是優秀的開源項目，從數據訪問框架 ORM到依賴注入容器，再到WEB層的MVC框架、AOP，基本包括了整個開發過程當中的全部東西，爲咱們快速的構建企業級的應用程序提供了很好的服務

Ninject：是一個快如閃電、超輕量級的基於.Net平臺的依賴注入框架。它可以幫助你把應用程序分離成一個個鬆耦合、高內聚的模塊，而後用一種靈活的方式組裝起來。經過使用Ninject配套你的軟件架構，那麼代碼將會變得更加容易編寫、重用性強、

易於測試和修改。

關於上面介紹的部分IOC容器的用法總體上來講都差很少，具體的你們能夠網上搜索下，案例和demo比較多。

2、多層架構

上面介紹了普通的三層架構，多層架構顧名思義就是在三層架構之上，經過擴展及應用場景的挖掘，衍生出來的適應不一樣場景的架構模式，下面我主要是來介紹如下幾種多層架構模式

A、服務層模式

在上面介紹的3層架構模式中，存在一個缺陷，若是咱們構建的軟件或系統支持分佈式或者須要對外提供服務的時候，這個場景就沒法知足了，因此這個時候服務層就出現了，就是在BLL層的基礎上進行包裝，包裝成能夠對外提供調用的分佈式服務。

通過改造後的項目結構以下：

在項目中加入了03.解決方案文件夾，同時添加項目 ThreeArchitecture.Service項目。

ThreeArchitecture.Service:主要是提供幾個做用：一、將業務邏輯層進行封裝，對外提供業務服務調用。二、經過外觀模式，屏蔽業務邏輯內部方法。三、下降業務邏輯層與UI層的依賴，業務邏輯接口或實現的變化不會影像UI層。四、下降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.三、前端分層架構

A、MVC架構模式

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯和數據顯示分離的方法組織代碼，將業務邏輯被彙集到一個部件裏面，在界面和用戶圍繞數據的交互能被改進和個性化

定製的同時而不須要從新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。

目前在主流的框架中都支持該模式，例如構建winform程序中能夠經過MVC模式來分離界面層中的控件與後端服務間的交互。下降耦合及依賴。

web上經過asp.net MVC框架來實現前端頁面及後端控制器之間的隔離。

視圖

視圖是用戶看到並與之交互的界面。對老式的Web應用程序來講，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演着重要的角色，但一些新的技術已層出不窮，它們包括Adobe Flash和像XHTML，XML/XSL,WML

等一些標識語言和Web services.

MVC好處是它能爲應用程序處理不少不一樣的視圖。在視圖中其實沒有真正的處理髮生，無論這些數據是聯機存儲的仍是一個僱員列表，做爲視圖來說，它只是做爲一種輸出數據並容許用戶操縱的方式。

模型

模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。一個模型能爲多個視圖提供數據，因爲應用於模型的代碼只需寫一次就能夠被多個視圖重用，因此減小了代碼的重複性。

控制器

控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求，因此當單擊Web頁面中的超連接和發送HTML表單時，控制器自己不輸出任何東西和作任何處理。它只是接收請求並決定調用哪一個模型構件去處理請求，而後再肯定用哪一個視圖來顯示返回的數

據。

ASP.NET 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也是比較困難的，至少那些業務邏輯是沒法重用的。

一、View和Model徹底解耦，二者不發生直接關聯，經過Presenter進行通訊。

二、Presenter並非與具體的View耦合，而是和一個抽象的View Interface耦合，View Interface至關於一個契約，抽象出了對應View應實現的方法。只要實現了這個接口，任何View均可以與指定Presenter兼容，從而實現了P Logic的複用性和視圖的無縫替換。

三、View在MVP裏應該是一個「極瘦」的概念，最多也只能包含維護自身狀態的邏輯，而其它邏輯都應實如今Presenter中。

總的來講，使用MVP模式能夠獲得如下兩個收益：

一、將UI和P Logic兩個關注點分離，獲得更乾淨和單一的代碼結構。

二、實現了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來寫。

1. 視圖(View)

視圖負責界面和顯示。它經過DataContext(數據上下文)和ViewModel進行數據綁定，不直接與Model交互。能夠綁定Behavior/Comand來調用ViewModel的方法，Command是View到ViewModel的單向通行，經過實現Silverlight提供的IComand接口來實現綁定，讓View觸發事件，ViewModel來處理事件，以解決事件綁定功能。

2. 視圖模型(ViewModel)

視圖模型主要包括界面邏輯和模型數據封裝，Behavior/Command事件響應處理，綁定屬性定義和集合等。它是View和Model的橋樑，是對Model的抽象，好比：Model中數據格式是「年月日」，能夠在ViewModel中轉換Model的數據爲「日月年」供View顯示。

實現視圖模型須要實現Silverlight提供的接口INotifyPropertyChanged， INotifyPropertyChanged接口用於實現屬性和集合的變動通知(Change Notifications)。使得在用戶在視圖上所作的操做均可以實時通知到視圖模型，從而讓視圖模型對象有的模型進行正確的業務操做。

View的代碼隱藏(Code-Behind)部分可能包含界面邏輯或者應用邏輯的代碼，這些代碼會很難進行單元測試，應根據具體狀況儘可能避免。

3. 模型(Model)

Model與MVC模式同樣，Model用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。它具備對數據直接訪問的權利，例如對數據庫的訪問，Model不依賴於View和ViewModel，也就是說，模型不關心會被如何顯示或是如何被操做，

模型也不能包含任何用戶使用的與界面相關的邏輯。Model在實際開發中根據實際狀況能夠進行細分。好比在廣州市城鄉規劃資源平臺就將Model將Service和Reposiroty結合爲WCF服務由ViewModel進行調用。

通常來講實際的項目中會採用如下的模式來作，而不是直接採用傳統的MVVM模式，而是結合MVP或MVC模式來作。

上圖中的P層是整個項目的核心，負責處理View層顯示的數據來源及用戶操做的響應的處理，經過綁定viewModel中的command的處理來與後端服務進行交互，展現器層會調用後端的WCF服務來讀取數據，也就是讀取DataModel 而後修改View

Model。經過WPF提供的通知機制，來修改view的呈現。

MVC、MVP、MVVM對比

標題	MVC	MVP	MVVM
特色	高內聚、低耦合-一個控制器能夠控制多個視圖	高內聚、低耦合-解決MVC中View依賴Model的問題	高內聚、低耦合-解決winform中存在的問題。解決view和Model之間的依賴，屏蔽view改變帶來的影響。
應用場景	前端與後端交互架構設計（CS或BS）	前端與後端交互架構設計（CS或BS）	前端與後端交互架構設計-WPF或Web經過js實現