asp.net-mvc-3 – IoC对泛型的关注点分离

发布时间：2020-12-16 06:31:04 所属栏目：asp.Net 来源：网络整理

导读：我的项目组织如下 ASP.NET MVC 3 WebApp Domain.Core – 接口[库] Domain.Core.Entity – 实体[library] Infrastructure.Core – 接口的实现[库] Infrastructure.IoC – 使用Unity作为实现控制反转的手段[图书馆] 困境如下：如果我要将一个泛型方法添加到我

我的项目组织如下

> ASP.NET MVC 3 WebApp
> Domain.Core – 接口[库]
> Domain.Core.Entity – 实体[library]
> Infrastructure.Core – 接口的实现[库]
> Infrastructure.IoC – 使用Unity作为实现控制反转的手段[图书馆]

困境如下：

如果我要将一个泛型方法添加到我的Domain.Core中的接口,如下所示,我收到一个编译错误,要求我在Infrastructure.IoC项目中添加对Domain.Core.Entity的引用.

T Get<T>(int Id) where T : EntityBase,new();

T可以是继承自EntityBase的EntityBase或Blog类,也可以是从EntityBase继承的一些其他实体.我们的想法是根据提供的子类返回一个实体,以便子类加载实现EntityBase的所有类所需的默认数据.

所以,问题有两个：

>在IoC项目中不引用Domain.Core.Entity项目并保持清洁是否更好？
>我如何实现上述内容而不必混淆参考文献的清洁度？

谢谢.

注意：我在这里经历了一些问题来搜索这个主题,但没有看到任何问题.如果您确实看到了,请告诉我,我将删除此问题.

解决方法

使用依赖注入,最好有一个组件负责组成所有各种协作者.这是Nat Pryce的 Third-Party Connect概念中的第三方,或者我称之为 Composition Root.在上面概述的体系结构中,这个责任似乎落在了Infrastructure.IoC上,所以考虑到这种结构,添加来自Infrastructure的引用没有任何问题. IoC到Domain.Core.Entity – 事实上,如果不是这样,我会发现它更令人惊讶.

但是,作为反馈的总体内容,我认为值得考虑具有单独的Infrastructure.IoC库实际获得的好处.该应用程序的入口点(ASP.NET MVC应用程序)需要引用Infrastructure.IoC,它还必须引用所有库才能组成它们.因此,ASP.NET MVC应用程序最终会对所有其他库进行间接引用,您也可以合并这两个库.

(从技术上讲,您可以依靠某种后期绑定机制(例如XML配置或约定优先配置)来解耦各种库,但是Infrastructure.IoC的概念职责将保持不变.)

有关详细信息,您可能需要阅读以下答案：Ioc/DI – Why do I have to reference all layers/assemblies in entry application?

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!