Контейнер IoC во всех случаях? (против статического класса)

Question

Я молодой разработчик, который начинает, я просто изучаю инъекцию зависимости, и у меня есть вопрос, который меня мучает.

В моем примере у меня есть веб-сервис WCF (мыло), он выполняет некоторые простые бизнес-действия и делает звонок в базу данных.

Итак, мой проект нарезают

Service -> Бизнес Layer -> Access Layer Data -> База данных

в моем случае, есть простое деловое мероприятие в бизнес-слой и SELECT, даного в уровень доступа к данным.

Так что теперь (конечно, неправильно) я использовал статический класс для общения между моими слоями:

В итоге:

Service Layer:

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

Бизнес слой:

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

Уровень доступа к данным:

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

Во-первых, это плохой путь?

Тогда для этого очень простого случая, стоит ли устанавливать контейнер IoC?

Заранее спасибо.

PS: Извините за мой английский

Answer 1

Я хотел бы сделать интерфейсы из ваших классов слоев. Это удаляет статические классы, как желаемые, и устанавливает вас для инъекций. Для вашего примера, который является довольно небольшим, я бы не стал советоваться с проблемой, если только в качестве учебного опыта. Нет жестких правил, когда использовать эту инъекцию, но шаблон очень помогает, когда происходит тестирование устройства.

Никто никогда не говорил: «Ого! Было бы намного проще написать единичный тест, если бы это был статический метод или синглтон!»

В конце вы получите что-то вдоль линий интерфейса для функциональности, которую вы хотите ввести. Это предполагает, что некоторый уровень модели домена будет существовать, и исходные данные из базы данных будут преобразованы в модель.

Вы должны начать с определения интерфейса, который вы должны ввести в зависимые классы.

public interface IBusinessLayer 
{ 
    Data GetData(); 
} 

public interface IDataAccessLayer 
{ 
    Data GetData(); 
} 

public interface IDatabase 
{ 
    DbData GetDatabaseData(); 
} 

Основная цель состоит в том, чтобы контейнер ввел функциональность, чтобы завершить выполняемые операции. В этом, получая данные. Предполагая, что данные являются классом в модели домена.

public class ServiceLayer 
{ 
    IBusinessLayer business = null; 

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

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

Вы можете повторить один и тот же шаблон для разных слоев. Хотя это кажется большой работой для простого приложения, жесткий край, данный интерфейсами, позволяет каждому слою эволюционировать на собственном ... до тех пор, пока остается договор с интерфейсом.

Сегрегация хорошая, если вы четко определяете слои. Например, не позволяя необработанным данным базы данных, рядам и т. Д. Выводиться в верхние слои.

общественный класс 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; 
    } 
}