好吧，在阅读了.Net中的依赖注入这本书后，我最终重新设计了它（我强烈向任何面向对象的开发人员推荐这本书，不仅仅是 .Net 开发人员，也不仅仅是那些对使用 IoC 容器感兴趣的人！）。
现在，我在 Domain 程序集中获得了以下内容：
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
}
}
Well I ended up redesigning this after reading the book Dependency Injection in .Net (I highly recommend this book to any object-oriented developer, not just .Net developers and not just those interested in using an IoC container!).
I've now got the following in a Domain assembly:
public interface IImageFileService
{
void RenameFiles();
void CopyFiles();
}
public interface IImageLinkMapRepository
{
IList<ImageLink> GetImageLinks();
}
Then in a FileAccess assembly I've created implementations for these interfaces:
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
}
}
So essentially, I've removed the need for primitive types in my constructor, at least for this class. At some point I did need that information, but that was injected into the ImageLinkMapRepository where the information made more sense. I used autofac named parameters to handle injecting them.
So I guess to answer my own question, primitive constructor parameters are a good idea if they make sense, but make sure you put them where they belong. If things don't seem to be jiving properly, it can probably be improved by rethinking the design.
In your example what you are actually passing are dependencies, but moreover data needed by the class to operate.
In your case it sounds like the methods RenameFiles() and CopyFiles() operate on the parameters that are passed to them. Given their names I would think that the methods on a single instance of ImageFileGenerator can be called with different parameters. If that is true arguably the parameters should be on the method calls themselves not the constructor.
If, on the other hand, on one instance RenameFiles() and CopyFiles() are each only called once with the same parameters the parameters would be good candidates for the constructor.
I personally would try to avoid property injection for required dependencies - in that case constructor injection is much more appropriate.
发布评论
评论（2）
好吧，在阅读了.Net中的依赖注入这本书后，我最终重新设计了它（我强烈向任何面向对象的开发人员推荐这本书，不仅仅是 .Net 开发人员，也不仅仅是那些对使用 IoC 容器感兴趣的人！）。
现在，我在 Domain 程序集中获得了以下内容：
然后在 FileAccess 程序集中，我创建了这些接口的实现：
因此，从本质上讲，我已经消除了构造函数中对基元类型的需求，至少对于此类而言是这样。在某些时候，我确实需要这些信息，但这些信息被注入到 ImageLinkMapRepository 中，在那里信息更有意义。我使用 autofac 命名参数 来处理注入它们。
所以我想回答我自己的问题，原始构造函数参数如果有意义的话是一个好主意，但请确保将它们放在它们所属的位置。如果事情看起来不太正常，可能可以通过重新思考设计来改进。
Well I ended up redesigning this after reading the book Dependency Injection in .Net (I highly recommend this book to any object-oriented developer, not just .Net developers and not just those interested in using an IoC container!).
I've now got the following in a Domain assembly:
Then in a FileAccess assembly I've created implementations for these interfaces:
So essentially, I've removed the need for primitive types in my constructor, at least for this class. At some point I did need that information, but that was injected into the ImageLinkMapRepository where the information made more sense. I used autofac named parameters to handle injecting them.
So I guess to answer my own question, primitive constructor parameters are a good idea if they make sense, but make sure you put them where they belong. If things don't seem to be jiving properly, it can probably be improved by rethinking the design.
在您的示例中，您实际传递的是依赖项，但此外数据是类操作所需的。
在您的情况下，听起来方法
RenameFiles()和CopyFiles()对传递给它们的参数进行操作。考虑到它们的名字，我认为可以使用不同的参数调用单个ImageFileGenerator实例上的方法。如果这是真的，那么参数应该位于方法调用本身而不是构造函数上。另一方面，如果在一个实例上，
RenameFiles()和CopyFiles()仅使用相同的参数调用一次，则这些参数将是构造函数的良好候选者。我个人会尝试避免对必需依赖项进行属性注入 - 在这种情况下构造函数注入更合适。
In your example what you are actually passing are dependencies, but moreover data needed by the class to operate.
In your case it sounds like the methods
RenameFiles()andCopyFiles()operate on the parameters that are passed to them. Given their names I would think that the methods on a single instance ofImageFileGeneratorcan be called with different parameters. If that is true arguably the parameters should be on the method calls themselves not the constructor.If, on the other hand, on one instance
RenameFiles()andCopyFiles()are each only called once with the same parameters the parameters would be good candidates for the constructor.I personally would try to avoid property injection for required dependencies - in that case constructor injection is much more appropriate.