Упрощение композиционных интерфейсов в C#

Question

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

Одним из примеров является ввод в него IRepository, который содержит доступ к репозиторию данных. И IRepository содержит DatabaseContext, который записывает в базу данных через повторно IDbContext, который вводится.

SoftwareSession - единственная внедренная общая инфраструктура для доступа к базе данных, действующей в качестве шлюза. Это означает, что когда я хочу написать объект в базу данных, например WriteCar, мне нужно будет реализовать 3 интерфейса, 2 функции делегирования составленным объектам и 1 функцию с реализацией. Это поясняется в фрагменте кода ниже. Подписи WriteCar определяются одинаково в трех интерфейсах (IRepository, ISoftwareSession, IDbContext), 2 места, где он не реализован (репозиторий, SoftwareSession), который просто вызывает связанные функции связанных объектов и 1 место фактической реализации (IDbContext)

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

Я думаю, что это обеспечивает наилучшую среду для улучшения тестируемости, и она следует лучшим практикам, когда сеанс программного обеспечения обертывает доступ к репозиторию и репозиторию, обертывает доступ к контекстам данных, - но я все еще сомневаюсь, если мы сможем немного улучшить его запись , или у меня есть непонимание какой-либо концепции в коде ниже?

Что представляет собой архитектурно более удобный способ реализации этого? Может быть, даже используя какой-то умный способ лямбда или делегатов уменьшить количество кода, написанного для каждой новой функции? Или даже некоторые библиотеки (например, automapper упрощают DTO) или инструменты для облегчения генерации этого кода из какого-то механизма шаблонов с помощью Visual Studio, Resharper и т. Д.?

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

public class SoftwareSession : ISoftwareSession 
{ 
    ... 
    IRepository repository; 
    public void WriteCar(Car car){ 
     repository.WriteCar(car); 
    } 
    ... 
} 

public interface ISoftwareSession{ 
    ... 
    void WriteCar(Car car); 
    ... 
} 


public class Repository : IRepository{ 
    ... 
    IDbContext context; 
    public void WriteCar(Car car){ 
     context.WriteCar(car); 
    } 
    ...   
} 

public interface IRepository{ 
    ... 
    void WriteCar(Car car); 
    ... 
} 

public class MyDbContext : IDbContext{ 
    ... 
    public void WriteCar(Car car){ 
     //The Actual Implementation here. 
     ... 
    } 
    ... 
} 

public interface IDbContext{ 
    ... 
    void WriteCar(Car car); 
    ... 
} 

Answer 1

С одной стороны, ваш IDbContext и IRepository одинаковы. Вам, вероятно, захочется удалить IDbContext или, по крайней мере, удалить из него методы, объявленные в IRepository.

Тогда как MyDbContext и Repository будут осуществлять IRepository и Repository класса будет просто обертка MyDbContext.

Затем, если Repository только переадресовывает вызовы на MyDbContext, то вам, вероятно, и этот класс не нужен.

Кроме того, я не вижу, что вы делаете что-либо в SoftwareSession, кроме пересылки вызова в содержащийся репозиторий. Вам действительно нужно SoftwareSession, или было бы целесообразно передать IRepository непосредственно тому, кто вызывает объект сеанса?

Суть заключается в том, что эта реализация подвержена дублированию и пересылке. Удалите это, и вся ваша модель станет простой.

Answer 2

Не видя корни композиции, я не совсем уверен, как работает ваша реализация, но я бы предложил изучить использование контейнера Inversion of Control (IoC). Поскольку ваша реализация ISoftwareSession зависит только от экземпляра IRepository, вам нужно только ввести это в конструктор класса. То же самое касается и вашей реализации IRepository: вам нужно только ввести свой IDbContext в конструктор.

С контейнером IoC вы «регистрируетесь», то есть подключаете свои интерфейсы к своей реализации при запуске приложения (в корне состава), и контейнер заботится о создании необходимых экземпляров при разрешении зависимостей. Тогда все, что вам нужно сделать, это получить экземпляр SoftwareSession из контейнера, и вы уйдете.

Таким образом, вы можете изменить SoftwareSession реализации, как это:

public class SoftwareSession : ISoftwareSession 
{ 
    IRepository repository; 

    public SoftwareSession(IRepository repository) 
    { 
     this.repository = repository; 
    } 

    public void WriteCar(Car car) 
    { 
     repository.WriteCar(car); 
    } 
} 

И ваша Repository реализация так:

public class Repository : IRepository 
{ 
    IDbContext context; 

    public Repository(IDbContext dbContext) 
    { 
     context = dbContext; 
    } 

    public void WriteCar(Car car) 
    { 
     context.WriteCar(car); 
    } 
} 

Тогда вот ваш состав корня:

var ioc = new MyIocContainer(); 

// register your interfaces and their associated implementation types with the IoC container 
ioc.Register<ISoftwareSession, SoftwareSession>(); 
ioc.Register<IRepository, Repository>(); 
ioc.Register<IDbContext, MyDbContext>(); 

// resolve the IoC container 
ioc.Resolve(); 

// get your `ISoftwareSession` instance 
var session = ioc.GetConcrete<ISoftwareSession>(); 

var newCar = new Car(); 

session.WriteCar(newCar);