溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹C#中依賴倒置原則DIP的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
我們先來看看傳統的三層架構，如下圖所示：
從上圖中我們可以看到：在傳統的三層架構中，層與層之間是相互依賴的，UI層依賴于BLL層，BLL層依賴于DAL層。分層的目的是為了實現“高內聚、低耦合”。傳統的三層架構只有高內聚沒有低耦合，層與層之間是一種強依賴的關系，這也是傳統三層架構的一種缺點。這種自上而下的依賴關系會導致級聯修改，如果低層發生變化，可能上面所有的層都需要去修改，而且這種傳統的三層架構也很難實現團隊的協同開發，因為上層功能取決于下層功能的實現，下面功能如果沒有開發完成，則上層功能也無法進行。
傳統的三層架構沒有遵循依賴倒置原則（DIP）來設計，所以就會出現上面的問題。
依賴倒置(DIP)：Dependence Inversion Principle的縮寫，主要有兩層含義：
高層次的模塊不應該依賴低層次的模塊，兩者都應該依賴其抽象。
抽象不應該依賴于具體，具體應該依賴于抽象。
我們先來解釋第一句話：高層模塊不應該直接依賴低層模塊的具體實現，而是應該依賴于低層模塊的抽象，也就是說，模塊之間的依賴是通過抽象發生的，實現類之間不應該發生直接的依賴關系，他們的依賴關系應該通過接口或者抽象類產生。
在來解釋第二句話：接口或者抽象類不應該依賴于實現類。舉個例子，假如我們要寫BLL層的代碼，直接就去實現了功能，等到開發完成以后發現沒有使用依賴倒置原則，這時候在根據實現類去寫接口，這種是不對的，應該首先設計抽象，然后在根據抽象去實現，應該要面向接口編程。
我們在上面說過，在傳統的三層架構里面沒有使用依賴倒置原則，那么把依賴倒置原則應用到傳統的三層架構里面會如何呢？我們知道，在傳統的三層架構里面，UI層直接依賴于BLL層，BLL層直接依賴于DAL層，由于每一層都是依賴下一層的實現，所以說當下層發生變化的時候，它的上一層也要發生變化，這時候可以根據依賴倒置原則來重新設計三層架構。
UI、BLL、DAL三層之間應該沒有直接的依賴關系，都應該依賴于接口。首先應該先確定出接口，DAL層抽象出IDAL接口，BLL層抽象出IBLL接口，這樣UI層依賴于IBLL接口，BLL實現IBLL接口。BLL層依賴于IDAL接口，DAL實現IDAL接口。如下圖所示：
我們上面講了依賴倒置原則，那么依賴倒置原則的目的是什么呢？
有了依賴倒置原則，可以使我們的架構更加的穩定、靈活，也能更好地應對需求的變化。相對于細節的多變性，抽象的東西是穩定的。所以以抽象為基礎搭建起來的架構要比以細節為基礎搭建起來的架構要穩定的多。
在傳統的三層架構里面，僅僅增加一個接口層，我們就實現了依賴倒置，目的就是降低層與層之間的耦合。有了這樣的接口層，三層架構才真正實現了“高內聚、低耦合”的思想。
依賴倒置原則是架構層面上的，那么如何在代碼層面上實現呢？下面看控制反轉。
控制反轉(IOC)：Inversion of Control的縮寫，一種反轉流、依賴和接口的方式，它把傳統上由程序代碼直接操控的對象的控制器（創建、維護）交給第三方，通過第三方（IOC容器）來實現對象組件的裝配和管理。
IOC容器，也可以叫依賴注入框架，是由一種依賴注入框架提供的，主要用來映射依賴，管理對象的創建和生存周期。IOC容器本質上就是一個對象，通常會把程序里面所有的類都注冊進去，使用這個類的時候，直接從容器里面去解析。
依賴注入(DI)：Dependency Injection的縮寫。依賴注入是控制反轉的一種實現方式，依賴注入的目的就是為了實現控制反轉。
依賴注入是一種工具或手段，目的是幫助我們開發出松耦合、可維護的程序。
依賴注入常用的方式有以下幾種：
構造函數注入。
屬性注入。
方法注入。
其中構造函數注入是使用最多的，其次是屬性注入。
看下面的一個例子：父親給孩子講故事，只要給這個父親一本書，他就可以照著這本書給孩子講故事。我們下面先用最傳統的方式實現一下，這里不使用任何的設計原則和設計模式。
首先定義一個Book類：
namespace DipDemo1
{
public class Book
{
public string GetContent()
{
return "從前有座山，山上有座廟.....";
}
}
}然后在定義一個Father類：
using System;
namespace DipDemo1
{
public class Father
{
public void Read()
{
Book book = new Book();
Console.WriteLine("爸爸開始給孩子講故事了");
Console.WriteLine(book.GetContent());
}
}
}然后在Main方法里面調用：
using System;
namespace DipDemo1
{
class Program
{
static void Main(string[] args)
{
Father father = new Father();
father.Read();
Console.ReadKey();
}
}
}我們來看看關系圖：
我們看到：Father是直接依賴于Book類。
這時需求發生了變化，不給爸爸書了，給爸爸報紙，讓爸爸照著報紙給孩子讀報紙，這時該怎么做呢？按照傳統的方式，我們這時候需要在定義一個報紙類：
namespace DipDemo1
{
public class NewsPaper
{
public string GetContent()
{
return "新聞";
}
}
}這時依賴關系變了，因為爸爸要依賴于報紙了，這就導致還要修改Father類：
using System;
namespace DipDemo1
{
public class Father
{
public void Read()
{
// 讀書
// Book book = new Book();
//Console.WriteLine("爸爸開始給孩子講故事了");
//Console.WriteLine(book.GetContent());
// 報紙
NewsPaper paper = new NewsPaper();
Console.WriteLine("爸爸開始給孩子講新聞");
Console.WriteLine(paper.GetContent());
}
}
}假設后面需求又變了，又不給報紙了，換成雜志、平板電腦等。需求在不斷的變化，不管怎么變化，對于爸爸來說，他一直在讀讀物，但是具體讀什么讀物是會發生變化，這就是細節，也就是說細節會發生變化。但是抽象是不會變的。如果這時候還是使用傳統的OOP思想來解決問題，那么會導致程序不斷的在修改。下面使用工廠模式來優化：
首先創建一個接口：
namespace DipDemo2
{
public interface IReader
{
string GetContent();
}
}然后讓Book類和NewsPaper類都繼承自IReader接口，Book類
namespace DipDemo2
{
public class Book : IReader
{
public string GetContent()
{
return "從前有座山，山上有座廟.....";
}
}
}NewsPaper類：
namespace DipDemo2
{
public class NewsPaper : IReader
{
public string GetContent()
{
return "王聰聰被限制高消費......";
}
}
}然后創建一個工廠類：
namespace DipDemo2
{
public static class ReaderFactory
{
public static IReader GetReader(string readerType)
{
if (string.IsNullOrEmpty(readerType))
{
return null;
}
switch (readerType)
{
case "NewsPaper":
return new NewsPaper();
case "Book":
return new Book();
default:
return null;
}
}
}
}里面方法的返回值是一個接口類型。最后在Father類里面調用工廠類：
using System;
namespace DipDemo2
{
public class Father
{
private IReader Reader { get; set; }
public Father(string readerName)
{
// 這里依賴于抽象
Reader = ReaderFactory.GetReader(readerName);
}
public void Read()
{
Console.WriteLine("爸爸開始給孩子講故事了");
Console.WriteLine(Reader.GetContent());
}
}
}最后在Main方法里面調用：
using System;
namespace DipDemo2
{
class Program
{
static void Main(string[] args)
{
Father father = new Father("Book");
father.Read();
Console.ReadKey();
}
}
}我們這時候可以在看看依賴關系圖：
這時Father已經和Book、Paper沒有任何依賴了，Father依賴于IReader接口，還依賴于工廠類，而工廠類又依賴于Book和Paper類。這里實際上已經實現了控制反轉。Father（高層）不依賴于低層（Book、Paper）而是依賴于抽象（IReader），而且具體的實現也不是由高層來創建，而是由第三方來創建（這里是工廠類）。但是這里只是使用工廠模式來模擬控制反轉，而沒有實現依賴的注入，依賴還是需要向工廠去請求。
下面繼續優化代碼，這里只需要修改Father類：
using System;
namespace DipDemo3
{
public class Father
{
public IReader Reader { get; set; }
/// <summary>
/// 構造函數的參數是IReader接口類型
/// </summary>
/// <param name="reader"></param>
public Father(IReader reader)
{
Reader = reader;
}
public void Read()
{
Console.WriteLine("爸爸開始給孩子講故事了");
Console.WriteLine(Reader.GetContent());
}
}
}在Main方法里面調用：
using System;
namespace DipDemo3
{
class Program
{
static void Main(string[] args)
{
var f = new Father(new Book());
f.Read();
Console.ReadKey();
}
}
}如果以后換成了Paper，需要修改代碼：
using System;
namespace DipDemo3
{
class Program
{
static void Main(string[] args)
{
// Book
//var f = new Father(new Book());
//f.Read();
// Paprer
var f = new Father(new Paper());
f.Read();
Console.ReadKey();
}
}
}由于這里沒有了工廠，我們還是需要在代碼里面實例化具體的實現類。如果有一個IOC容器，我們就不需要自己new一個實例了，而是由容器幫我們創建實例，創建完成以后在把依賴對象注入進去。
我們在來看一下依賴關系圖：
下面我們使用Unity容器來繼續優化上面的代碼，首先需要在項目里面安裝Unity，直接在NuGet里面搜索即可：
這里只需要修改Main方法調用即可：
using System;
using Unity;
namespace UnityDemo
{
class Program
{
static void Main(string[] args)
{
// 創建容器
var container = new UnityContainer();
// 掃描程序集、配置文件
// 在容器里面注冊接口和實現類，創建依賴關系
container.RegisterType<IReader, Book>();
// 在容器里面注冊Father
container.RegisterType<Father>();
// 從容器里拿出要使用的類，容器會自行創建father對
// 還會從容器里去拿到他所依賴的對象，并且注入進來
//
var father = container.Resolve<Father>();
// 調用方法
father.Read();
Console.ReadKey();
}
}
}以上是“C#中依賴倒置原則DIP的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
