Question

我目前正在研究如何重构现有的非模块化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/

便携式区域似乎不是一种好方法，因为它们要求将视图编译为Area项目文件中的嵌入资源。这将阻止IIS缓存。另一方面，我真的无法想象性能缺点究竟有多大。

使用MEF的基于MVC的模块

http://www.fidelitydesign.net/?p=104

为了在其他项目中创建松散耦合的服务，我非常依赖MEF。因此我认为使用它来发现ASP.NET MVC模块/插件是个好主意。我最终会使用一个ControllerFactory来实例化使用'Export'属性导出的控制器。这样我就可以完全控制插件实例化，并可以使用MEF来获取服务。然而，使用MEF确实需要比使用MVC区域更多的工作，MVC区域解决了开箱即用的控制器。

插件项目中的实体框架

到目前为止，我无法解决的一个问题是如何在各个插件项目中分发实体。目前，我们使用Database First方法，该方法由一个包含所有实体的* .edmx模型文件组成。即使使用DbContext或Code First，也不可能为一个数据库使用多个DbContext类。一种想法是使用MEF将来自不同插件的实体加载到中央DbContext类中。但是我不知道这是否是支持和/或推荐的设置。

Answer 1

另一种选择是使用我的Griffin.MvcContrib。它可以为您处理所有管道，并允许您编写视图并使用几乎没有代码更改的区域。

将它与IoC容器一起使用，以获得强大的插件系统。

以下文章演示了如何：http://www.codeproject.com/Articles/386674/ASP-NET-MVC-3-plug-in-architecture-using-Griffin-M

组合ASP.NET MVC Web应用程序（MEF，区域，DI）的最佳实践

1 个答案: