ASP.NET MVC 的插件架构 [英] Plug-in architecture for ASP.NET MVC

问题描述

我花了一些时间查看 Phil Haack 关于分组控制器 非常有趣的东西.

I've been spending some time looking at Phil Haack's article on Grouping Controllers very interesting stuff.

目前我正试图弄清楚是否可以使用相同的想法为我正在从事的项目创建插件/模块化架构.

At the moment I'm trying to figure out if it would be possible to use the same ideas to create a plug-in/modular architecture for a project I'm working on.

所以我的问题是:是否可以将 Phil 文章中的领域拆分到多个项目中?

So my question is: Is it possible to have the Areas in Phil's article split across multiple projects?

我可以看到名称空间会自行解决，但我担心视图会出现在正确的位置.是不是可以通过构建规则来解决?

I can see that the name spaces will work themselves out, but I'm concerned about the views ending up in the right place. Is it something that can be sorted out with build rules?

假设在单个解决方案中的多个项目都可以实现上述功能，是否有人对使用单独的解决方案和编码到一组预定义的接口使其成为可能的最佳方法有任何想法?从区域移动到插件.

Assuming that the above is possible with multiple projects in a single solution, does anyone have any ideas about the best way to make it possible with a separate solution and coding to a predefined set of interfaces? Moving from an Area to a plug-in.

我在插件架构方面有一些经验，但没有大量经验，因此这方面的任何指导都会很有用.

I have some experiences with plug-in architecture but not masses so any guidance in this area would be useful.

推荐答案

几周前我做了一个概念验证，我将一个完整的组件堆栈:模型类、控制器类和它们关联的视图放入一个 DLL 中，添加/调整了示例之一检索视图的 VirtualPathProvider 类，以便它们适当地处理 DLL 中的视图.

I did a proof of concept a few weeks ago where I put a complete stack of components: a model class, a controller class and their associated views into a DLL, added/tweaked one of the examples of the VirtualPathProvider classes that retrieve the views so they'd address those in the DLL appropriately.

最后，我只是将 DLL 放入一个适当配置的 MVC 应用程序中，它的工作方式就像它从一开始就是 MVC 应用程序的一部分一样.我进一步推动了它，它与 5 个小型 mini-MVC 插件配合得很好.很明显，在对它进行混洗时，您必须注意您的引用和配置依赖项，但它确实有效.

In the end, I just dropped the DLL into an appropriately configured MVC app and it worked just like if it had been part of the MVC app from the start. I pushed it a bit further and it worked with 5 of these little mini-MVC plugins just fine. Obviously, you have to watch your references and config dependencies when shuffling it all around, but it did work.

该练习针对我为客户端构建的基于 MVC 的平台的插件功能.在站点的每个实例中，有一组核心控制器和视图，这些控制器和视图由更多可选的控制器和视图增强.我们将把这些可选位制作成这些模块化的 DLL 插件.到目前为止一切顺利.

The exercise was aimed at plugin functionality for an MVC-based platform I'm building for a client. There are a core set of controllers and views that are augmented by more optional ones in each instance of the site. We're going to be making those optional bits into these modular DLL plugins. So far so good.

我写了一个关于我的原型的概述和一个示例解决方案用于 ASP.NET MVC 插件在我的网站上.

I wrote up an overview of my prototype and a sample solution for ASP.NET MVC plugins on my site.

4 年过去了，我一直在做很多带有插件的 ASP.NET MVC 应用程序，不再使用我上面描述的方法.在这一点上，我通过 MEF 运行我所有的插件并且根本不将控制器放入插件中.相反，我制作了使用路由信息来选择 MEF 插件并将工作交给插件等的通用控制器.只是想我会添加，因为这个答案受到了相当大的打击.

4 years on, I've been doing quite a few ASP.NET MVC apps with plugins and no longer use the method I describe above. At this point, I run all of my plugins through MEF and don't put controllers into plugins at all. Rather, I make generic controllers that use the routing information to select MEF plugins and hand the work off to the plugin, etc. Just thought I'd add since this answer gets hit a fair bit.

这篇关于ASP.NET MVC 的插件架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！