我一直在阅读很多关于依赖注入和服务定位器(反?)模式的内容——很多都在 StackOverflow 上(谢谢大家:)。我有一个关于这种模式在 n 层架构中如何工作的问题。
我看过很多博客文章,其中描述了将 IDataAccess 组件注入业务对象。例如
public class Address
{
IDataAccess _dataAccess;
public Address(IDataAccess dataAccess)
{
this._dataAccess = dataAccess;
}
}
但是,我的印象是,在 n 层架构中,UI 层应该不需要任何数据访问层的知识……甚至不需要知道 /is/ 有数据访问层!如果 DI 需要在 BusinessObjects 的构造函数中公开 IDataAccess 接口,那么这会向 UI 公开业务层在后台使用数据访问层的事实——这是 UI 不需要知道或关心的事情吗?
所以,我的基本问题是:DI 是否要求我将所有下层接口暴露给所有上层,这是好事还是坏事?
谢谢
编辑:为了澄清(经过几条评论),我知道我的业务对象应该不知道它使用哪个 IDataAccess 的具体实现(因此在构造函数中注入了依赖项),但我认为 BO 上方的层不应该知道业务对象甚至需要对 DAL 的依赖。