在我的模块化框架中声明我的Autofac模块的位置? [英] Where to declare my Autofac modules in my modular framework?

查看:106
本文介绍了在我的模块化框架中声明我的Autofac模块的位置?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

嘿,



我有一个包含很多程序集的通用框架,有些是常见的,有些是为服务器应用程序设计的,有些是为客户端应用程序设计的(每个功能都有一个基线库,而任何特定于应用程序类型的扩展都在不同的程序集中定义)。



我正在尝试决定在我的框架中我应该为我创建的不同模块声明Autofac注册模块。



我的代码完全解耦,并且在我的代码中根本没有使用IoC容器。此外,其他外部依赖项(如序列化程序,API程序集等)仅由将它们公开给框架的模块引用。这会导致一些程序集膨胀问题,因为我有(例如)整个程序集,它将JSON序列化调整到我的序列化接口中(将其隐藏在我的应用程序代码的其余部分中)。



我想到了几种可能的解决方案:



1.在每个模块曝光组件的顶部添加一个组件以适应Autofac模块。

- 主要优点是每个组件都将导出其模块,其所有功能将以模块化方式直接提供。

- 主要缺点是它可能是将我的组件数量增加一倍。



2.只添加几个可识别不同模块的Autofac感知组件(显然不是随机的),可能只包含一个用于特定应用程序的模块。

- 此解决方案增加了更少的过多程序集,但模块化程度较低,并且可能导致不必要的依赖性补间组中的所有程序集。此外,如果为特定应用程序存储库创建模块,则仅在该存储库中存在模块可重用性(并且在不同应用程序之间没有共享模块)。



3.创建我自己的我的框架中的模块注册合同接口,并为我正在使用的实际IoC容器创建一个合同消费者。

- 优点是每个程序集都可以包含没有任何依赖的模块(假设注册界面在我最基本的库中)。缺点是解决方案显然限制了我可以做的事情(类似于内部平台效应)。



我有什么替代方案吗?我没有看到更多优点/缺点吗?有没有人遇到类似的困境和他们应用的做法?



非常感谢!

Hey,

I have a general framework which contains a lot of assemblies, some are common, some are designed for Server applications, and some for Client applications (Each feature has a base-line library while any application-type-specific extensions are defined in a different assembly).

I'm trying to decide where in my framework I should declare Autofac registration modules for the different modules I create.

My code is completely decoupled and the IoC container is not used intrusively at all within my code. Also, other external dependencies (such as serializers, API assemblies, etc...) are referenced only by the modules that expose them to the framework. That causes some assembly-bloating issues because I have (for example) an entire assembly that adapts JSON serialization into my serialization interfaces (hiding it from the rest of my application code).

I thought about several possible solutions:

1. Adding an assembly to adapt with Autofac Modules on top of every "module-exposing" assembly.
- The main advantage is that every assembly will export its modules and all its the "functionalities" will be straight forward available in a modular fashion.
- The main disadvantage is that it probably will double the amount of assemblies I have.

2. Add only several Autofac-aware assemblies that will define different modules (Obviously not randomly), maybe one for containing the modules used for a specific application.
- This solution adds much less excessive assemblies, but is less modular, and causes possibly unwanted dependencies between all the assemblies in the group. Also if modules are created for a specific application repository, there is module reusability only within that repository (and no shared modules between different applications).

3. Create my own module registration "contract" interfaces within my framework and create a contract-consumer for the actual IoC container I'm using in order to adapt.
- The advantage is that every assembly can contain modules without any dependency (assuming the registration interfaces are in my most basic library). The disadvantage is that solution obviously limits the things I can do (similar to the "inner-platform" effect).

Are there any alternatives I'm missing? Are there more advantages/disadvantages that I fail to see? Did anybody experience anything similar dilemmas and the practices they've applied?

Thanks a lot!

推荐答案

这篇关于在我的模块化框架中声明我的Autofac模块的位置?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆