使用 IoC 容器时，原始构造函数参数是不是一个坏主意？ [关闭]

Question

标准新手免责声明：我是 IoC 新手，收到的信号不一。我正在寻找有关以下情况的一些指导。

假设我有以下接口和实现：

public interface IImageFileGenerator
{
    void RenameFiles();
    void CopyFiles();
}

public class ImageFileGenerator : IImageFileGenerator
{
    private readonly IList<IImageLink> _links;
    private readonly string _sourceFolder;
    private readonly string _destinationFolder;
    private readonly int _folderPrefixLength;

    public ImageFileGenerator(IList<IImageLink> links, string sourceFolder, string destinationFolder)
    {
        _links = links;
        _sourceFolder = sourceFolder;
        _destinationFolder = destinationFolder;
        _folderPrefixLength = 4;
    }

    public void RenameFiles()
    {
        // Do stuff, uses all the class fields except destination folder
    }

    public void CopyFiles()
    {
        // Do stuff, also uses the class fields
    }
}

我很困惑是否应该只将接口/依赖项发送给构造函数，创建一些参数对象并将其传递给构造函数，还是保持原样并在解析实例时传递参数。

那么有没有更正确的方法来设置此代码以最好地与 IoC 容器配合使用？与我当前的布局相比，以下哪一项在设计上更受欢迎？

1.

public interface IImageFileGenerator
{
    void RenameFiles(IList<IImageLink> links, string sourceFolder);
    void CopyFiles(IList<IImageLink> links, string sourceFolder, stringDestFolder);
}

public class ImageFileGenerator : IImageFileGenerator
{
    private readonly int _folderPrefixLength;

    public ImageFileGenerator()
    {
        _folderPrefixLength = 4;
    }

    public void RenameFiles(IList<IImageLink> links, string sourceFolder)
    {
        // Do stuff
    }

    public void CopyFiles(IList<IImageLink> links, string sourceFolder, stringDestFolder)
    {
        // Do stuff
    }
}

我不喜欢在两种情况下都传递完全相同的东西（目标文件夹除外）。在 IImageFileGenerator 的当前实现中，我需要执行这两个方法，并且每个方法都需要相同的值。这就是我通过构造函数传入状态的原因。

2.

public interface IImageFileGenerator
{
    void RenameFiles();
    void CopyFiles();
}

public class ImageLinkContext
{
    // various properties to hold the values needed in the
    // ImageFileGenerator implementation.
}

public class ImageFileGenerator : IImageFileGenerator
{
    private readonly IList<IImageLink> _links;
    private readonly string _sourceFolder;
    private readonly string _destinationFolder;
    private readonly int _folderPrefixLength;

    public ImageFileGenerator(ImageLinkContext imageLinkContext)
    {
        // could also use these values directly in the methods 
        // by adding a single ImageLinkContext field and skip 
        // creating the other fields
        _links = imageLinkContext.ImageLinks;
        _sourceFolder = imageLinkContext.Source;
        _destinationFolder = imageLinkContext.Destination;
        _folderPrefixLength = 4;
    }

    public void RenameFiles()
    {
        // Do stuff, uses all the class fields except destination folder
    }

    public void CopyFiles()
    {
        // Do stuff, uses all the class fields
    }
}

这种方法甚至可以调整为 Mark Seemann here 提到的外观服务（以前称为聚合服务）。

我还读到您可以为这些值使用属性并使用属性注入，尽管这似乎不再是首选（autofac 提到构造函数注入是首选... Ninject 我相信甚至删除了版本 2 中的功能)。

另外，我读到您还可以创建一个初始化方法并确保在其中设置属性。

有这么多的选择，当我阅读更多关于这些东西的信息时，我变得越来越困惑。我敢肯定没有明确的正确方法（或者至少对于这个例子来说可能有？），但也许有人可以提供每种方法的优缺点。或者也许还有另一种我完全错过的方法。

我现在意识到这个问题可能有点主观（实际上不仅仅是一个问题），但我希望你能原谅我并提供一些指导。

PS - 我目前正在尝试使用 autofac，以防影响哪种设计可能更适合。

注意：我对目标文件夹的代码做了一些细微的更改...... RenameFiles 不使用它（可能对您的回答有影响）。

Answer 1

好吧，在阅读了 Dependency Injection in .Net 这本书后，我最终重新设计了这本书（我强烈推荐这本书给任何面向对象的开发人员，不仅仅是 .Net 开发人员，也不仅仅是那些对使用 IoC 容器感兴趣的人！）。

我现在在域程序集中获得了以下内容：

public interface IImageFileService
{
    void RenameFiles();
    void CopyFiles(); 
}

public interface IImageLinkMapRepository
{
    IList<ImageLink> GetImageLinks(); 
}

然后在 FileAccess 程序集中，我为这些接口创建了实现：

public class ImageFileService : IImageFileService
{
    public ImageFileService(IImageLinkMapRepository repository)
    {
        // null checks etc. left out for brevity
        _repository = repository;
    }

    public void RenameFiles()
    {
        // rename files, using _repository.GetImageLinks(), which encapsulates
        // enough information for it to do the rename operations without this
        // class needing to know the specific details of the source/dest dirs.
    }

    public void CopyFiles() 
    { 
        // same deal as above
    }
}

所以本质上，我已经在构造函数中消除了对原始类型的需求，至少对于这个类来说是这样。在某些时候，我确实需要这些信息，但它被注入到 ImageLinkMapRepository 中，其中信息更有意义。我使用autofac named parameters 处理注入它们。

所以我想回答我自己的问题，如果它们有意义，原始构造函数参数是一个好主意，但请确保将它们放在它们所属的位置。如果事情似乎不正常，可能可以通过重新考虑设计来改进。

Answer 2

在您的示例中，您实际传递的是 依赖项，但此外，该类需要 data 进行操作。

在您的情况下，听起来RenameFiles() 和CopyFiles() 方法对传递给它们的参数进行操作。鉴于它们的名称​​我认为ImageFileGenerator 的单个实例上的方法可以使用不同的参数调用。如果这是真的，那么参数应该在方法调用本身而不是构造函数上。

另一方面，如果在一个实例上 RenameFiles() 和 CopyFiles() 仅使用相同的参数调用一次，则参数将是构造函数的良好候选者。

我个人会尽量避免 必需 依赖项的属性注入 - 在这种情况下，构造函数注入更合适。