架构问题:使用依赖注入导致垃圾API [英] Architecture problem: use of dependency injection resulting in rubbish API

查看:20
本文介绍了架构问题:使用依赖注入导致垃圾API的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试创建一个类,该类执行各种与数据库相关的低级操作,但为 UI 层提供了一个非常简单的界面.

I'm tring to create a class which does all sorts of low-level database-related actions but presents a really simple interface to the UI layer.

该类表示所有在特定聚合根中的一组数据,由单个 ID int 检索.

This class represents a bunch of data all within a particular aggregate root, retrieved by a single ID int.

构造函数接受四个参数:

The constructor takes four parameters:

public AssetRegister(int caseNumber, ILawbaseAssetRepository lawbaseAssetRepository, IAssetChecklistKctcPartRepository assetChecklistKctcPartRepository, User user)
{
  _caseNumber = caseNumber;
  _lawbaseAssetRepository = lawbaseAssetRepository;
  _assetChecklistKctcPartRepository = assetChecklistKctcPartRepository;
  _user = user;
  LoadChecklists();
}

UI 层通过接口IAssetRegister 访问该类.Castle Windsor 可以自己提供 ILawbaseAssetRepository 和 IAssetChecklistKctcPartRepository 参数,但 UI 代码需要使用匿名类型提供另外两个参数,如下所示:

The UI layer accesses this class through the interface IAssetRegister. Castle Windsor can supply the ILawbaseAssetRepository and IAssetChecklistKctcPartRepository parameters itself, but the UI code needs to supply the other two using an anonymous type like this:

int caseNumber = 1000;
User user = GetUserFromPage();
IAssetRegister assetRegister = Moose.Application.WindsorContainer.Resolve<IAssetRegister>(new { caseNumber, user});

从 API 设计的角度来看,这是垃圾.UI 层开发人员无法知道 IAssetRegister 需要一个整数和一个用户.他们需要了解类的实现才能使用它.

From the API design point of view, this is rubbish. The UI layer developer has no way of knowing that the IAssetRegister requires an integer and a User. They need to know about the implementation of the class in order to use it.

我知道我这里一定有某种设计问题.谁能给我一些指点?

I know I must have some kind of design issue here. Can anyone give me some pointers?

推荐答案

正如 Morten 所指出的,将不可注入的依赖从构造函数调用移到实际需要使用它的方法中,

As Morten points out, move the non injectable dependecies from the constructor call to the method(s) that actually need to use it,

如果您有无法(或难以)注入的构造函数参数,您将无法自动将 IAssetRegister 注入任何需要它的类.

If you have constructor paramters that can't (or are difficult to) be injected you won't be able to autmatically inject IAssetRegister into any class that needs it either.

当然,您始终可以创建一个具有以下具体实现的 IUserProvider 接口:

You could always, of course, create a IUserProvider interface with a concrete implementation along these lines:

public class UserProvider : IUserProvider 
{
    // interface method
    public User GetUser() 
    {
        // you obviously don't want a page dependency here but ok...
        return GetUserFromPage();
    }
}

因此在没有的地方创建了另一个可注入的依赖项.现在,您无需将用户传递给可能需要它的每个方法.

Thus creating another injectable dependency where there was none. Now you eliminate the need to pass a user to every method that might need it.

这篇关于架构问题:使用依赖注入导致垃圾API的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆