IoC與DI
- IoC
- Inversion of control，中文稱控制反轉。由Martin Fowler提出。這裡引用MVP 91哥的說明：
系統架構設計應該以抽象的邏輯概念為主，才能更貼近現實世界，才能更符合domain model，當Business logic不變時，需求變更、技術變更、DB變更，都應該要把風險和成本壓到最低。
- DI
- Dependency injection，中文稱相依注入。在IoC的思考模式與實作下，最終的結果就是相依於介面（Interface），但類別中最後只存有介面的話，程式是不會動的，這時我們就會利用DI技巧，在應用程式啟動時去注入介面所對應的實體（也就是一般我們在程式碼裡寫的
new ClassName()）。
MVC與Web API的Controller的IoC與DI處理
不管是在ASP.NET MVC或ASP.NET Web API，在Controller的概念上或本質上可以說是一模一樣。這裡主要差異點會是在DI套件的實作差異上。
Controller使用Respository Pattern處理資料實體相依
一般我們會透過基架（MVC 5將scaffold翻譯為基架）來產生MVC的Controller與View Page，或是Web API的API Controller。例如，使用Northwind資料庫的Product資料表來產生API Controller會是這樣：
public class ProductsController : ApiController
{
private NorthwindEntities db = new NorthwindEntities();
// GET api/Products
public IEnumerable<Product> GetProducts()
{
return db.Products.AsEnumerable();
}
// 省略
}
預設範本所產生的程式碼會產生與NorthwindEntities資料實體（new NorthwindEntities()）產生依賴關係。每個API Controller都還要處理db.Products，這造成API Controller的職責不夠單一，這在裡我們就先採用Repository Pattern 1來分離資料庫處理程式碼與API Controller的相依關係。
1 Repository Pattern實作請參考《
public class ProductsController : ApiController
{
//private NorthwindEntities db = new NorthwindEntities();
private IProductRepository _product;
public ProductsController() {
_product = new ProductRepository();
}
// 重要，但要等一下才會知道
public ProductsController(IProductRepository r)
{
_product = r;
}
// GET api/Products
public IEnumerable<Product> GetProducts()
{
return _product.GetAll();
}
// 省略
}
透過Repository Patter我們分離了資料庫相關程式碼，而且我們偷偷留下一個含介面參數的建構函式，等一下在討論這部分。就目前使用了Repository Pattern的Controller，就算刪除此含介面參數的建構函式，程式依然會正常運作。
但引入使用Repository Pattern後的API Controller產生了新的問題，這些API Controller又會與特定實體類別產生相依關係，我們必須在無參數建構函式去初始化一個實體類別，以呼叫分離後的資料庫處理程式（例如：_product = new ProductRepository();）。
