IoC-Container in allen Fällen? (gegen statische Klasse)

Question

Ich bin ein junger Entwickler, der beginnt, ich lerne nur Dependency-Injektion und ich habe eine Frage, die mich quält.

In meinem Beispiel habe ich ein WCF-Service-Web (Soap), es führt einige einfache Geschäftsaktionen aus und ruft die Datenbank an.

So wird mein Projekt geschnitten in

Service -> Business Layer -> Data Access Layer -> Datenbasis

in meinem Fall ist es einfache Geschäft Aktion in Business-Schicht und einer SELECT-Anweisung in Datenzugriffsschicht.

So, jetzt (sicherlich falsch) Ich verwendete statische Klasse zwischen meinen Schichten zu kommunizieren:

Zusammengefasst:

Service Layer:

public void GetData() 
     { 
      BusinessLayer.GetData(); 
     } 

Geschäftslage:

static class BusinessLayer 
    { 
     public static void GetData() 
     { 
      //If something or something else ... 
      DataAccessLayer.GetData(); 
     } 
    } 

Datenzugriffsschicht:

static class DataAccessLayer 
    { 
     public static void GetData() 
     { 
      //DO insert in database 
     } 
    } 

Erstens, ist das ein schlechter Weg zu gehen?

Dann, für diese Art von sehr einfachen Fall, lohnt es sich, einen IoC-Container einzurichten?

Vielen Dank im Voraus.

PS: Sorry für mein Englisch

Answer 1

würde ich Schnittstellen macht aus Ihrer Schicht Klassen. Dies entfernt die statischen Klassen wie gewünscht und richtet Sie für die Injektion ein. Für Ihr Beispiel, das eher klein ist, würde ich nicht empfehlen, das Problem durchzugehen, es sei denn als Lernerfahrung. Es gibt keine strengen Regeln für die Verwendung dieser Injektion, aber das Muster hilft enorm, wenn Komponententests durchgeführt werden.

Niemand hat jemals gesagt: "Wow! Das wäre viel einfacher gewesen, einen Komponententest zu schreiben, wenn es eine statische Methode oder Singleton wäre!"

Am Ende werden Sie etwas in Richtung der Schnittstelle für die Funktionalität haben, die Sie injizieren möchten. Dies setzt voraus, dass ein bestimmtes Domänenmodell existiert und Rohdaten aus der Datenbank in das Modell konvertiert werden.

Sie würden damit beginnen, die verschiedenen Schnittstellen zu definieren, die Sie in abhängige Klassen injizieren müssen.

Das Hauptziel ist es, den Container die Funktionalität injizieren zu lassen, um die gewünschten Operationen abzuschließen. In diesem erhalten Daten. Angenommen, Ihre Daten sind eine Klasse im Domänenmodell.

public class ServiceLayer 
{ 
    IBusinessLayer business = null; 

    public ServiceLayer(IBusinessLayer business) 
    { 
     this.business = business; 
    } 

    public void GetData() 
    { 
     Data data = business.GetData(); 
     // do something with data 
    } 
} 

Sie können das gleiche Muster für die verschiedenen Schichten wiederholen. Während dies für eine einfache Anwendung eine Menge Arbeit zu sein scheint, erlauben die durch die Schnittstellen gegebenen harten Kanten, dass sich jede Ebene selbst entwickelt ... solange der Schnittstellenvertrag bestehen bleibt.

Die Trennung ist nett, wenn Sie die Schichten klar definiert halten. Wenn Sie beispielsweise keine Rohdatenbankdaten zulassen, bluten Zeilen usw. in die oberen Schichten.

Öffentliche Klasse BusinessLayer: IBusinessLayer { IDataAccessLayer dataAccess = null;

// container will inject data access layer 
    public BusinessLayer(IDataAccessLayer dataAccess) 
    { 
     this.dataAccess = dataAccess; 
    } 

    public Data GetData() 
    { 
     Data data = dataAccess.GetData(); 
     // do something with data? 
     return data; 
    } 
} 

// Retruns typed data business layer 
public class DataAccessLayer : IDataAccessLayer 
{ 
    IDatabase db = null; 

    public DataAccessLayer(IDatabase db) 
    { 
     this.db = db; 
    } 

    public Data GetData() 
    { 
     var db_data = db.GetDatabaseData(); 
     Data data = /*convert raw db_data -> type domain data*/ 
     return data; 
    } 
}