从一个常见的模板应用程序"继承"ASP.NET MVC网站？(多租户)

Question

我们正在构建大约10个ASP.NET MVC站点,这些站点具有一组共同的功能(以及相应的URL,路由,控制器,操作和视图).这些站点还将共享一组域对象(例如用户,公司)和这些对象的基本属性(例如名称,地址等).

但每个站点也将高度定制并从基础扩展.例如,我们针对大型上市公司的网站将在公司域对象上具有"子公司"和"股票代码"字段,而我们的初创公司网站将具有"风险公司"和"资金"属性.虽然我们试图尽可能保持HTML的一致性(为额外的域对象属性建模额外的表单字段等),但外观也会有很大差异.我们也会谨慎地覆盖图像,因此我们可以在网站上重复使用相同的按钮图形.

无论如何,我们正试图弄清楚如何最好地分解和构建事物,以便我们可以重用尽可能多的代码和尽可能多的测试,而不会限制我们添加每个应用程序属性的自由,并改变应用程序之间的UI.

我熟悉如何处理有限的自定义多租户,就像你在StackOverflow/SuperUser/ServerFault(或MSDN/TechNet)中找到的那样,UI有点不同,数据模型或多或少相同.但是当模型和UI非常不同(但是从一个共同的基础继承)时,我不太清楚如何继续.

我不太担心操作问题,因为我们可能会在一个单独的appdomain中运行每个站点并将它们托管在不同的数据库中.我更担心的是降低长期代码维护成本,提高灵活性(例如,在不破坏衍生应用程序的情况下轻松添加新功能到基础),以及在构建第2版时实现短期开发/测试成本节省,第3,第4等网站.

我正在寻找高级指导和建议,但也有关于如何使用现代ASP.NET MVC实践来实现该指导的具体建议.

我意识到这是一个非常普遍的问题,但对于初学者,我正在寻找高级指导以及如何在ASP.NET MVC中应用该指导的具体技巧和技巧,包括:

• 建议在Visual Studio项目中拆分基础/派生的位置
• 源控制提示,以避免分叉
• 数据库架构提示(FWIW,我们的数据库都很小 - 每个表10K行以下,所以开发/测试成本比DB perf更重要)
• 有关重新使用控制器/视图/等的提示.对应于"基础"模型属性,尤其是重新使用UI,例如"新客户"表单,它们将具有基本属性和派生属性的混合.

对于如何构建这样的多租户应用程序,任何人都有很好的建议吗？

Answer 1

这就是我们的工作,目前大约有8个网站效果很好.

• 为您的控制器,ViewModel,HttpApplication,路由等定义核心MVC项目.这将编译成DLL并破坏您的大部分站点.

• 为您的站点创建一组基本的默认视图,脚本,图像等.这些将作为您的各个站点的默认服务器.

• 根据客户端,在编译到另一个dll的项目中创建您需要的任何自定义控制器,路由等.

• 此外,每个客户端,重新创建您要使用的任何视图,脚本,图像.

要使上述步骤协同工作,您需要编写一些胶水.第一块胶水是自定义视图引擎.您需要自定义标准视图引擎,以首先在特定于客户端的文件夹中查找视图,然后查找默认文件夹.这使您可以轻松覆盖每个客户端的默认布局.

让一切正常工作的第二种方法是让您的核心应用程序从客户端特定程序集加载路由,控制器等.为此,我使用Managed Extensibility Framework(MEF)来公开单个Register方法.在我的客户端汇编代码上调用此方法会注册路由和任何其他特定于客户端的需求.

以下是我的网站文件夹结构的一般视图,首先检查SiteContent的视图:

  - AppContent
  - AppContent/Static
  - AppContent/Static/Images
  - AppContent/Static/Scripts
  - AppContent/Static/Styles
  - AppContent/Views
  - AppContent/Views/Shared

  - SiteContent
  - SiteContent/Static
  - SiteContent/Static/Images
  - SiteContent/Static/Scripts
  - SiteContent/Static/Styles
  - SiteContent/Views
  - SiteContent/Views/Shared

  - web.config
  - Global.asax

我有可以使用的帮助程序,如SiteImage和AppImage,可以在我的视图中使用.此外,我让我的每个客户端站点都使用某些特定的名称作为他们的母版页,我没有在我的AppContent默认值中定义.

我意识到这是一个粗略的概述,但它现在对我们来说运作良好.

Answer 2

Mike Hadlow详细介绍了如何实现这一目标：

http://mikehadlow.blogspot.com/2008/11/multi-tenancy-part-1-strategy.html