当前位置:  开发笔记 > 后端 > 正文

同一层中的洋葱架构依赖关系:基础架构和Web通信

如何解决《同一层中的洋葱架构依赖关系:基础架构和Web通信》经验,为你挑选了1个好方法。

我正在使用Jeffrey Palermo描述的Onion架构设计ASP.NET MVC应用程序.

这是一个ASP.NET MVC 2.0项目中,我要求所有的视图中使用专用的视图模型是强类型的 - 我们不会通过域模型对我们的看法.我们使用AutoMapper进行翻译 - AutoMapper在基础架构中被隔离,Web不知道或不关心AutoMapper的使用.

目前,我正在Web项目中定义IViewModelMapping接口 - 只是因为控制器将使用此服务,并且它可以直接访问自己的View模型.这样,界面可以访问域模型(在Core中)和View模型(在Web中).

为了提供IViewModelMapping接口的实际实现,我在Infrastructure项目中创建了一个ObjectMapping命名空间,它将实际的映射实现与洋葱的Intrastructure隔离开来.在这样做时,这将要求Infrastructure依赖于BOTH Core AND Web.

我的问题是:由于这两个项目在技术上都位于洋葱的郊区(在同一层中) - 是否允许一个项目依赖于该层中的另一个项目?有没有人注意到这个设计有任何潜在的陷阱?

另一种设计是将IViewMapper接口移动到Core中 - 但这是不可能的,因为Core无法访问ViewModel类.我也可以将视图模型移动到Core中,但我觉得它们不属于那里,因为它们特定于UI层.

建议的体系结构如下 - 请注意,基础结构依赖于Core和Web.Web保持隔离状态,只能访问Core业务逻辑.

http://www.matthidinger.com/images/onion-arch.png



1> Jeffrey Pale..:

你是不正确的,你不希望基础设施依赖于UI(Web),但我有时会打破这个规则.

我认为不是使用IViewModelMapping,而是使用方法Map()创建IMapper.然后,接口可以具有可能与视图模型映射有关的实现,或者可能只是常规映射.无论哪种方式,该接口都可以在Core中,因为它在语义上不绑定到任何类型的模型.

伟大的图形.我希望我能回答你的问题.洋葱架构的整体理念是将您的业务逻辑和模型保持在应用程序的中间(核心),并尽可能向外推送您的依赖项.


谢谢Jeffrey.现在我要重新考虑设计,但可能保持原样,直到它给我带来任何重大的麻烦.对我来说最重要的是我不会做出任何我以后无法解决的决定:)
推荐阅读
路人甲
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有