Asp.net MVC 使用Autofac的簡單使用 IOC

來源:互聯網
上載者:User
  Ioc(Inversion of Control)或者叫依賴注入DI(Dependency Injection)  如果一個介面有兩個實作類別,但是在實現過程中,用到了這兩個具體的實作類別。  如果採用IOC,則只能是註冊一個介面類型,那麼如何確保IOC在合適的時候傳入不同類的執行個體?這是我突然間想到的一個問題,希望園友們可以幫忙解答一下!

 

  所謂IOC(控制反轉)或者說是依賴注入,就是將你設計好的類交給系統去控制,而不是在你的類內部控制,控制權發生了變化,就稱為控制反轉。   IOC的使用時機就是在一個介面有多個實作類別的情況下,並且還可能存在擴充這個介面的可能性的情況下使用我個人覺得是最好的。   我們使用抽象介面來隔離使用者和具體實作類別之間的依賴?誰依賴誰呢?我們要清楚的明白這個關係才能更好的明白如何使用IOC。我以為是使用者依賴具體的實現。  IOC表示的是依賴注入,但是這個表示誰依賴誰呢? Class A{IB _b;public A(){_b=new ImpB();//在調用實作類別的ImpB中方法  定義一個該類型的變數  採用介面定義方式  ,這個採用介面定義的方式,可以用來叫做面向介面的編程,這個在現在也是一種很常用的方式。不採用面向抽象編程而是採用面向介面編程。}} Class ImpB:IB{//具體的實作類別}class ImpC:IB{//C具體的實現}但是如果採用IOC方式,只需要在A的建構函式中傳入必須的參數。這就會出現上面我提到的兩個實作類別的問題。還有我還要提出一個問題,一個實作類別繼承自兩個介面,那麼如何進行值的注入呢?  關於IOC的幾個概念: 服務:     組件       自動裝配 所謂服務,就是一系列的介面,介面約定了服務,從而使隨意的更換實現介面的具體實現不會對使用該服務的代碼進行任何的更改。面向服務的編程   ==面向介面的編程? 組件:組件是一個可重用的程式單元,是實現了某個具體介面並且僅僅實現了該介面的實作類別。組件是實現了某個服務介面的類。具體的實作類別。 自動裝配(Auto Wiring):指的是由容器自動管理組件之間的依賴關係。自動在需要具體實現的時候通過某種注入方式注入需要的執行個體。 IOc也屬於一種設計模式,它主要是用來協調各個組件之間的組合關係。增加了程式的可遷移性以及良好的組件解耦。不需要在實作類別中使用new 來執行個體化對象,避免了組件類之間的耦合,也避免了在需要更改具體時候的時候更改程式的內部代碼實現。 IOC很好的解決了這個問題,它把組件之間的關係由程式內部提到外部容器來管理,也就是說由容器在運行期間將組件間的依賴關係動態注入組件中。控製程序間關係的實現交給了外部容器來管理,這就是所謂的好萊塢法則。不要找我,我會找你。 下面還有一個要注意的就是關注點分類(SOC),這應該算是IOC的最初的目的,實現關注點的分離,通過分解程式,把程式分解成一個個的功能點,然後確保每個功能點都是沒有相互直接聯絡的。這就是關注點分離原則。在IOC將控制權轉移到自己手上的時候其實就是就是解除了組件之間的實際依賴關係,解除了組件(也就是實作類別)直接的直接耦合。實現了基本的關注點分離原則。 還有一個設計原則叫做面向切面的編程原則(AOP),這種方式是縱向的看待程式功能。 我個人認為IOC是一個理論,這DI則是具體實現方式, 現在我來提一個問題?為什麼我們必須要在application_start方法中註冊autofac或ioc,以便進行組件解耦? 答:我們知道無論是asp.net web form還是MVC,最終都是運行在.Net framework 之上,通過IIS控制從頁面請求到頁面響應的整個過程。每個請求從進入到最後響應(暫且稱為聲明周期)都是被asp.net 工作者進程把持,因為我們無法直接的控制該進程,所以我們想在整個生命週期內進行注入的可能性基本上就不存在。既然這樣,我們就只能是在生命週期開始之前就進行注入。在一個請求從進入到響應會經過IIS的很多處理,其中IhttpModule 管線就可以被我們使用來進行依賴注入。這也就解釋了為什麼我們只能在程式啟動之前註冊。   Autofac是在IOC理論下和C#緊密結合的一個架構,它提供了相對其他架構所不可比擬的優勢: 1.使用C#泛型2.可以方便的註冊Asp.net MVC Controller3.支援C# lambda運算式,以及對linq的完美支援4.具有無侵入性,可以在運行時對對象的執行個體以及聲明周期進行管理5.輕量級的架構 Autofac的簡單使用:1.註冊類型的簡單,無需任何xml配置就可以使autofac正常運行。當然autofac也可以通過xml設定檔進行配置。 public void ApplicationStart()  {var builder=new ContainerBuilder();//建立autofac管理註冊類的容器執行個體//下面就需要為這個容器註冊它可以管理的類型//builder.Register... builder的register方法可以通過多種方式註冊類型//其實register這些方法我們有必要詳細的瞭解一下,畢竟每種方法都可以找到針對的使用地方 //builder.Build();//產生具體的執行個體 //下面就是使用MVC的擴充 更改注入方式             var container=builder.Build();            DependencyResolver.SetResolver(new Autofac.Integration.Mvc.AutofacDependencyResolver(container));//更改了MVC中的注入方式}2.在homeController中使用建構函式注入public class HomeController{private Inet _net;public HomeController(Inet net)//介面定義  建構函式注入{_net=net;  //我們在運行時通過單步調試就可以看到net其實就是我們實現介面Inet的具體執行個體。前提是已經正確註冊了autofac並且正確的進行配置}public ActionResult(){var result=_net.GetAll();//調用具體類的具體方法返回結果return view(result); //進行值的傳遞}} 這樣我們就可以在項目中使用autofac作為組件來管理我們的程式,進行控制權的轉移。 總結一下,IOC本質上就是使使用者的控制權轉移到單獨的組件上(autofac),通過各種方式的注入來達到組件之間的解耦,實現關注點分離的效果。autofac的使用非常簡單,我就不再舉例說明,我只是說明了IOC的使用背景。 我沒有看過autofac的原始碼,不知道我的認識是不是正確,如果有錯誤,請你指出來,我會積極改正,謝謝。 還有IOC只是一種手段,不是目的,不是我們設計架構時應該考慮的事情,這隻是我們在實現時採用的技巧,當然也有其他方法可以達到類似的效果,也有很多這樣的組件可以達到這個效果。我們的最終目的是實現關注點的分離以及組件之間的耦合度最低。  
相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.