我目前正在研究如何重构现有的不是非常模块化的 ASP.NET MVC 3.0 应用程序的体系结构。我有一个类似插件的结构，以使现有项目可扩展。
我已经搜索了制作模块化 Web 应用程序的不同策略，并发现了以下内容。我希望你对这些想法发表评论。
- 不同项目中的 MVC 区域
对于每个插件，我想创建一个单独的 ASP.NET MVC 项目，其中包含插件的控制器、视图和视图模型。“员工”模块将包含一个用于列出、创建、更新和删除员工的区域。不过这听起来不错，AreaRegistration 需要将所有区域放在“bin”目录中。我找到了一种将我的 Area 项目直接放在 Areas 文件夹中并从“/Areas/[AreaName]/bin”文件夹中解析 Area 程序集的方法：
BuildManager.AddReferencedAssembly.Add(Assembly.LoadFrom(…));
AppDomain.CurrentDomain.AssemblyResolve += ResolveAssemblies;
这工作得很好，允许我在主项目的 Areas 文件夹中部署插件。我喜欢使用 ASP.NET MVC 开箱即用的区域功能。
- MVC 可移植区域 (MVCContrib)
http://elegantcode.com/2012/04/06/mvc-portable-areas/
可移植区域似乎不是一个好方法，因为它们要求将视图编译为区域项目文件中的嵌入资源。这将阻止 IIS 缓存。另一方面，我真的无法想象性能缺陷到底有多大。
- 使用 MEF 的基于 MVC 的模块
http://www.fidelitydesign.net/?p=104
为了在其他项目中创建松散耦合的服务，我严重依赖 MEF。因此，我认为使用它来发现 ASP.NET MVC 模块/插件是一个好主意。我最终会使用一个 ControllerFactory 来实例化使用“Export”属性导出的控制器。这样我就可以完全控制插件实例化并且可以使用 MEF 来获取服务。然而，使用 MEF 确实需要比使用开箱即用的控制器的 MVC 区域需要更多的工作。
- 跨插件项目的实体框架
到目前为止，我无法解决的一个问题是如何在各个插件项目中分配实体。目前我们使用数据库优先方法，它由一个包含所有实体的 *.edmx 模型文件组成。即使使用 DbContext 或 Code First，也不可能为一个数据库使用多个 DbContext 类。一种想法是使用 MEF 将来自不同插件的实体加载到中央 DbContext 类中。但是我不知道这是否是受支持和/或推荐的设置。