我已经阅读了很多关于依赖项注入(inject)和服务定位器(反?)模式的文章——很多都是在 StackOverflow 上的(谢谢大家 :)。我对这种模式在 n 层架构中的工作方式有疑问。
我看过很多博客文章,其中描述了将 IDataAccess 组件注入(inject)到业务对象中。例如
public class Address
{
IDataAccess _dataAccess;
public Address(IDataAccess dataAccess)
{
this._dataAccess = dataAccess;
}
}
然而,我的印象是,在 n 层架构中,UI 层不需要了解数据访问层......甚至不需要知道有/是/数据访问层!如果 DI 需要在 BusinessObjects 的构造函数中公开 IDataAccess 接口(interface),这就会向 UI 公开业务层在幕后使用数据访问层的事实 - UI 不需要知道或关心的事情?
因此,我的基本问题是:DI 是否要求我将所有下层接口(interface)暴露给所有上层,这是好事还是坏事?
谢谢
编辑:为了澄清(经过一些评论),我知道我的业务对象应该不知道它使用哪个 IDataAccess 的哪个特定实现(因此在构造函数中注入(inject)了依赖项)但是我认为 BO 之上的层不应该知道业务对象甚至需要对 DAL 的依赖。
最佳答案
这确实是一个相当复杂的话题,并且有很多方法可以实现 n 层架构。没有一种方法是“正确的方法”,您如何使用取决于您的需求和您的个人喜好。
依赖注入(inject)是关于管理依赖的。如果您的对象不知道任何依赖性,那么您就不会按照您提到的方式编写您的对象。相反,您将有一些其他服务或方法以不可知的方式填充数据。数据也不意味着“数据库”。所以 IDataAccess 可能意味着它来自数据库,或者来自网络套接字,或者来自磁盘上的文件。这里的重点是 Address 不选择它创建的依赖项。这是通过组合根的配置完成的。
事物需要数据,否则您的应用可能毫无用处。然而,让您的 Address 对象自行加载可能不是解决问题的最佳方法。更好的方法可能是使用工厂类或服务方法。
关于c# - 依赖注入(inject)与分层架构,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17919823/