我们当前的想法是,即使MVC使用非常简单的控制器(仅推荐其他代码)(如推荐的那样)来完成其自然结论,但这些视图将是一个难题,因为它们不适合这种可组合性,任何情况都不是我们一直在使用的Razor.很难对它们进行子类化并说“对于这个客户来说,做一些额外的事情”;特别是,对于相同的构造,很难为稍微不同的HTML提供服务.
我们无法弄清楚多租户和单租户的工作是否干净,我们不希望分叉代码库,即使一个或多个客户的定制是彻底的. (在可能的范围内,我们希望保持所有客户的数据库结构同构,我想这是我们为多租户做的方式,但每个租户都必须是他们自己的IIS网站,因为规模和隔离.)即使我们想出了一种覆盖一层自定义视图的方法,也会在视图中出现轻微的逻辑不匹配.
这样做的现有技术是什么？什么是战争故事？ (这可能是主观的,但它主要是客观的,如果有一种模式或方法完全将其降低到其本质,当然这是正确的答案.我认为这是一个有趣的问题.)
我很乐意提供更多细节.
解决方法
我使用的策略是：
>专注于功能和配置,而不是客户.我们为每个机构提供一系列核心功能.这些功能中只有少数可以自定义.对于每个机构,我们维护一个Web.Config转换,其中包含对可自定义功能的选择.发布设置用于控制在发布该机构的应用时使用的转换.视图/控制器使用配置数据来实现为该机构指定的功能的变体.它不知道它是哪个机构,只是配置说“在渲染小部件C时执行A而不是B”.
>将主题分为常见和特定于站点的组件.大多数CSS /图像对所有机构都是通用的,但是,我们最后加载特定于站点的CSS,允许覆盖特定站点.这主要是颜色,背景和机构特定的图像(横幅等).我们将特定于站点的主题放在内容/主题中的单独文件夹中.配置项用于设置主题文件夹,主视图在构造CSS的URL和任何特定于站点的图像(大多数(如果不是全部)图像在站点CSS文件本身中处理时)拉动此配置项.
>维护包装标准配置的强类型配置类.无论何时需要配置,都要将此类注入控制器,邮件程序等.因为我们依赖于整个应用程序的配置,所以我们认为将其推广到我们模型中的一流实体对于可读性和可维护性非常重要.对于非二元选项,我们通常会创建映射到设置的枚举,以避免字符串比较.对于更复杂的应用程序或更多的机构,我甚至可能会开发一个单独的配置节处理程序,并将配置分成它自己的部分或配置文件.目前,我们使用appsettings因为设置数量很少而且相对简单.
希望这可以帮助.
