爲什麼在我們的項目中需要接口層/抽象類？

Question

我們通常在我們的項目中使用抽象函數/接口。爲什麼它真的需要？爲什麼我們不能只是去業務邏輯層，數據訪問和表示層只

功能展示層：

abc(); 

---

功能在業務邏輯層：

public void abc() 
    { 
     //Preparing the list 
    } 

---

功能在數據訪問層：數據訪問SQLServer的層

public abstract void abc(); 

---

功能：

public override void abc() 
    { 
     //Connection with database 
    } 

---

問題是：爲什麼需要對數據訪問層？

Answer 1

理解這個的最簡單方法是imo，它是一個超過DataLayer的抽象。

您已經設置了從xml文件檢索數據的功能。但有一天，您的產品會向外擴展，並且xml還不夠，就像數據存儲一樣。所以你傳遞給一些嵌入式數據庫：sqlite。但有一天你需要在一些企業環境中重用你的庫。所以，現在你需要制定訪問sqlserver，oracle，webservice ....在所有這些變化，你將需要改變不僅實際訪問數據的代碼，但是代碼實際上消耗這一點。那麼在客戶端使用多年的第一個數據訪問代碼並滿意它的代碼呢？如何兼容？

具有抽象如果不是direcly解決了大多數的此類問題，但絕對會讓scallable您的應用程序和變化更有抵抗力，即，在我們的世界，有時發生過於頻繁。

Answer 2

一般來說，如果你在代碼中使用的接口，那麼你將在依賴注入的形式獲得代碼manuverability。

這將幫助你更換你的實現部分在例如單元測試期間提供Mock對象特定情況下。

Answer 3

我想你是在談論Facade層。

這是一個可選層這將簡化業務層的功能。讓我們想象一下，你有一個ProductManager和CategoryManager和你想做的事，其中包括使用兩個（例如，讓我排名前5的產品在所有類別），那麼你可以使用使用ProductManager和CategoryManager一個門面層中的特定作用。

它的靈感來源於Facade Pattern。

Answer 4

抽象有助於創建功能，無論是通過基類，接口還是組合，在正確使用時，它們都會爲維護，可讀性和代碼的可重用性帶來奇蹟。

關於問題中發佈的代碼，標記爲「數據訪問層」的代碼充當業務層使用的通用抽象。通過這樣做，DAL的特定實現（例如示例中的「數據訪問SQLServer層」下的內容）與業務層分離。現在，您可以訪問不同的數據庫，或者是自動送料測試數據DAL等實現

Repository模式是這個工作一個夢幻般的例子在DAL（例如簡化）：

public interface IProductRepository 
{ 
    Product Get(int id); 
    ... 
} 

public class SqlProductRepository : IProductRepository 
{ 

    public Product Get(int id) { ... } 
    ... 
} 

public class MockProductRepository : IProductRepository 
{ 
    private IDictionary<int, Product> _products = new Dictionary<int, Product>() 
    { 
     { 1, new Product() { Name = "MyItem" } } 
    }; 

    public Product Get(int id) { return _products[id]; } 
    ... 
} 

public class AwesomeBusinessLogic 
{ 
    private IProductRepository _repository; 

    public AwesomeBusinessLogic(IProductRepository repository) 
    { 
     _repository = repository; 
    } 

    public Product GetOneProduct() 
    { 
     return _repository.GetProduct(1); 
    } 
} 

即使此示例使用接口，同樣適用於使用基類。美麗的是，現在我可以喂SqlProductRepository或MockProductRepository到AwesomeBusinessLogic和不必改變任何關於AwesomeBusinessLogic。如果出現其他情況，所需的全部是IProductRepository和AwesomeBusinessLogic的新實現將仍然處理它，因爲它只通過接口訪問存儲庫。

Answer 5

所有以前的答案可能會解釋抽象層的需求，但我仍然想補充一些我的想法。

假設在我們的項目中，我們只是在每一層都有一個服務實現。舉例來說，我有一個接觸DAL和BLL接觸服務，我們可以做這樣的事情

namespace Stackoverflow 
{ 
    public class ContactDbService 
    { 
     public Contact GetContactByID(Guid contactID) 
     { 
      //Fetch a contact from DB 
     } 
    } 
} 

聯繫BLL服務：

namespace Stackoverflow 
{ 
    public class ContactBLLService 
    { 
     private ContactDbService _dbService; 
     public ContactBLLService() 
     { 
      _dbService = new ContactDbService(); 
     } 

     public bool CheckValidContact(Guid contactID) 
     { 
      var contact = _dbService.GetContactByID(contactID); 

      return contact.Age > 50; 

     } 
    } 
} 

沒有定義接口/抽象類。

如果我們這樣做，會有一些明顯的缺點。

1. 代碼通訊： 試想一下，如果你的項目涉及您的服務可能有很多不同的方法，維護者（除了你）怎麼會知道你的服務怎麼辦？他是否必須閱讀您的整個服務才能修復像InvalidCastOperation這樣的小錯誤？ 通過查看界面，人們將直接瞭解該服務的功能（至少）。

2. 單元測試

   你可以使用一個假/模擬服務提前檢測錯誤，並防止迴歸bug從後來發生的測試邏輯。

3. 容易改變：

   通過僅通過接口引用其他類/抽象類，你可以很容易地更換後的接口實現工作沒有太多的努力。

Answer 6

抽象類或接口是不是一個真正的單獨的層 - 它應該是你的業務邏輯層的一部分，它定義了實際的數據訪問層（SQL數據存儲庫，例如）需要實現接口爲您的業務層提供數據訪問服務。

如果沒有這個接口，您的業務層將直接依賴於SQL層，而接口將消除這種依賴關係：將抽象類或接口放入業務邏輯層。然後，SQL層（例如一個單獨的程序集）實現抽象類/接口。這樣SQL層依賴於業務層，而不是相反。

結果是一個靈活的應用程序，具有獨立的業務層，可以與多個數據存儲庫一起工作 - 它只需要一個實現業務層定義的接口的層。它不僅僅是關於數據存儲庫 - 你的業務層不應該依賴於上下文（asp.net與控制檯應用程序或服務等），它不應該依賴於用戶界面類，模塊接口與您的業務應用等

Answer 7

爲什麼接口： 你曾經使用C＃使用： 使用（FORM F =新表（）） { }

在這裏，你會看到你只能使用內的那些類，使用實現IDisposable接口。

兩件彼此不認識的東西只能通過Interfaces進行交互。 接口保證「某些」功能確實已通過此類型實現。

爲什麼層：

所以，你可以有單獨的DLL，這將讓你在不同應用程序中重用。

基本上所有的代碼重用和性能增益。

Answer 8

抽象使您能夠快速進行重構。考慮使用SQL服務器而不是使用SQL服務器，您決定使用其他提供程序;如果你沒有數據訪問層，那麼你需要做一個巨大的重構，因爲你直接調用數據訪問方法。但是，如果您有數據訪問層，則只需編寫一個新的數據訪問層，從抽象數據訪問層繼承，並且不會更改業務層中的任何內容。