依赖注入和附加功能

Question

这是我的一般问题，所以我会把它归结为非常小的问题。让我们有一个通用服务的接口。

第一部分

public interface IGenericService<T>
{
    void Create(T add);
    void Read();
    void Update(T obj);
    void Delete(T obj);
}

它的实现：

 public class DogService : IGenericService<Dog>
 {
     void Create(Dog add){}
     void Read(){}
     void Update(Dog obj){}
     void Delete(Dog obj){}
 }

第二个 repo 有一些独特的附加功能，比如 Miau()

 public class CatService: IGenericService<Cat>
 {
     void Create(Cat add){}
     void Read(){}
     void Update(Cat obj){}
     void Delete(Cat obj){}
     void Miau(){}
 }

现在，当使用一些 IOC 时，我会选择：

Bind<IGenericService<Dog>,DogService>
Bind<IGenericService<Cat>,CatService>

现在在 Viewmodel 的某处：

public class CatsViewModel
{
    public CatsViewModel(IGenericService<Cat> catService)
    {
        //how to have Miau functionality here?
    }
}

1.How 我可以在这里使用 Miau 功能吗？我应该为 DogService 创建第二个接口，例如 IDogService 并在这里以这种方式使用它吗？那么通用回购的目的是什么？

第二部分 让我们有这样的 GenericViewModel：

public abstract class GenericViewModel<T>
{
    T Collection { get; }
    public GenericViewModel(IGenericService<T> service)
    {
        Collection = service.Read();
    }
}

这很好。但是如果我想将它与 CatService

一起使用呢？

public class CatViewModel : GenericViewModel<Cat>
{
    public CatViewModel(IGenericService<T> service) : base(service)
    {
        // make miau here?
    } 
}

我是否应该创建 ICatService 接口并使用两个不同的接口注入同一服务的实例？我知道我可以从 IGenericService 转换它，因为我知道这是什么类型的服务，但这是一种好方法吗？

这些问题是关于良好习惯的，而不是关于有效的解决方案:)

Answer 1

我想到了几个选项：

非通用接口

What is the purpose of generic repo then ?

确实，这样做的目的是什么？为每个目的键入一个界面有多难？

public interface IDogService
{
    void Create(Dog add);
    void Read();
    void Update(Dog obj);
    void Delete(Dog obj);
}

public interface ICatService
{
    void Create(Cat add);
    void Read();
    void Update(Cat obj);
    void Delete(Cat obj);
    void Miau();
}

现在每个消费者都可以请求他们需要的依赖项。 ICatService 的客户可以消费 Miau.

将额外的行为作为额外的依赖项传递

另一个选择是保留通用 IGenericService<T>，但为 Miau 功能添加另一个服务：

public interface IMiauService
{
    void Miau();
}

然后让需要IMiauService的客户通过他们的构造函数请求它：

public class CatsViewModel
{
    private readonly IGenericService<Cat> catService;
    private readonly IMiauService miauService;

    public CatsViewModel(IGenericService<Cat> catService, IMiauService miauService)
    {
        this.catService = catService;
        this.miauService = miauService;
    }

    // Members can use both services as needed...
}

此解决方案暗示了第三种更好的选择：

遵循依赖倒置原则

根据Dependency Inversion Principle，客户应该定义他们需要的API，然后由具体的classes来实现API。

因此，如果 class 需要 read 和 write 功能，它应该通过声明相应的接口来宣传该需求：

public interface IReader<T>
{
    T Reader();
}

public interface IWriter<T>
{
    void Write(T item);
}

public class GenericViewModel<T>
{
    private readonly IReader<T> reader;
    private readonly IWriter<T> writer;

    public GenericViewModel(IReader<T> reader, IWriter<T> writer)
    {
        this.reader = reader;
        this.writer = writer;
    }

    // Members can use the reader and writer services...
}

像 OP IGenericService<T> 这样的界面闻起来像是在确定需求之前就已经定义好的东西，而现在您正试图将方钉装入圆孔中。

依赖注入和附加功能

Dependency injection and additional functionality

c#

dependency-injection

inversion-of-control

非通用接口

将额外的行为作为额外的依赖项传递

遵循依赖倒置原则