.net – 依赖注入 – 它是否违反了关注点?
发布时间:2020-12-14 04:58:32 所属栏目:百科 来源:网络整理
导读:依赖注入是否违反了与n层架构相关的问题分离? 假设您有以下项目: MyApp.DataMyApp.BusinessMyApp.Web 如果我使用DI告诉业务层使用哪种数据上下文,这不会违反SoC吗?这意味着UI(MyApp.Web)必须具备数据访问层(MyApp.Data)的知识才能告诉业务层(MyApp.Busine
依赖注入是否违反了与n层架构相关的问题分离?
假设您有以下项目: MyApp.Data MyApp.Business MyApp.Web 如果我使用DI告诉业务层使用哪种数据上下文,这不会违反SoC吗?这意味着UI(MyApp.Web)必须具备数据访问层(MyApp.Data)的知识才能告诉业务层(MyApp.Business)使用哪个上下文,对吧? public class WebForm { public void Save(Object dto) { BusinessObject bo = new BusinessObject(Data.MyDataContext); bo.ValidateAndSave(dto); } } 我一直认为,在n层架构中,每个层应该只具备下一层(UI到业务,业务到数据)的知识.这不是什么大不了的事吗? 解决方法
一般来说,你是对的.但是,依赖注入往往被认为是“配置”而不是表示层的一部分(即使它通常通常存在于那里).如果您的UI组件被设计为不了解数据层,那么这才是真正重要的.
如果您正在设计一个可测试的系统,那么业务和数据层应该独立于UI,但必须要配置它们.您可以创建另一个名为MyApp.Configuration的层来完成所有这些,但是大多数人发现这是过度工程的. 重要的是您的组件是否设计得很好,而不是UI是否具有其他层的一些配置知识. 它与Web.Config中的应用程序设置没有什么不同.毕竟,除非您使用面向服务的体系结构,否则一切都在同一个进程中运行在同一个计算机上.如果您使用的是SoA,那么您可以在各自的服务器上配置各个部分. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |