Asp.net 将GAC用于多个提供相同内容的网站-好/坏/其他？

我们为多个客户开发了一个网站门户，门户之间的差异非常小。2-3张图片和网站上的可用内容

若我们将其和汽车经销商门户网站进行比较，一个客户将展示丰田汽车，另一个福特和沃尔沃，另一个丰田和日产，多个网站将展示客户选择的汽车

目前，系统是代码的复制/粘贴版本，并根据需要对代码库进行更改。经销商品牌、联系信息和其他小选项的图像

这些网站的核心功能完全相同，按品牌展示汽车，展示新车和二手车

我们正在计划重新编写系统，Lead希望将数据库调用、页面显示代码放入DLL并将其注册到GAC

我曾试图说服他放弃这个计划，但结果却失败了。我需要一些实质性的文档来说明为什么在向GAC注册的DLL中进行数据库调用和放置代码不是一种最佳做法，或者说是一种错误的做法

我创建了两个网站，使用相同的代码库，使用HostHeaders调用带有中间件的数据库，根据hostheader搜索返回的数据集显示所需的数据。这种方法更容易接受吗

有人尝试过使用GAC吗？ 如果是，您在应用程序的维护周期中遇到了什么问题？ 使用GAC进行数据库调用是否存在任何安全问题

你的处境（我的解释）

听起来您的情况是ECM（企业内容管理）。 在这种情况下，您基本上需要一个核心产品，该产品提供页面、文档、再保险等，并使用系统内置的核心身份验证模型

这样一个系统将是一个支持主题化和定制等场景的单一应用程序（想想wordpress，但更多的是“enterprisey”）

虽然有定制，但实际上它最终是一个核心平台，因此GAC不会让您受益

。。。GAC迎合了这样一种场景：您拥有一个“Windows平台应用程序套件”，所有这些套件都共享一些通用的“可靠”组件，这些组件不会有太大的变化

关于您的ECM情况

在您的情况下，业务会经常变化，核心内容的“版本”也会经常变化，最终结果将是您的团队必须管理GAC的高开销，随着时间的推移，随着您的扩展，会有大量GAC以及随之而来的配置文件地狱

扮演魔鬼代言人（假设我错了）

更进一步，假设为了完整性，我错了，那么你有一个情况，你正在计划一个商业模式，包括每个新客户每次都有一个“你产品的新版本”，所以假设10年后，你有1000个客户，现在，这需要至少10台服务器，所有这些服务器都进行GAC管理，并且每个服务器都承载基本上是“某些核心功能上的配置”的子集

您的构建和部署过程使用powershell编写了大量脚本，以在大量服务器上替换这些基于GAC的核心组件，这需要花费数周的时间才能运行，并且会导致massiv edisruption

当您想要“迁移到云”时，普通的“web部署”类型的场景将不会为您带来更多的麻烦和问题

不过我确实做了一两个假设

我假设所讨论的产品至少是基于web的，但最终基于云的和管理云实例的最佳方法是将应用部署到容器中，而不是部署到服务器（理想模式）

现在，您有了一个阻止您遵循理想模型的系统，您必须“取消”您对GAC的依赖，但GAC对我来说就像是.Net提供的一个遗留功能，它服务于未来，而不是在软件建模方面发生巨大变化的“通用”现在使用.Net core的方法是将.Net本身的大部分与应用程序一起部署到任何平台，其中许多平台可能不理解GAC的概念

我的建议

我认为这里真正发生的事情是，您的技术负责人关注服务器上的代码复制（或程序集复制），并且正在寻找一种方法，去一个地方管理给定程序集的1个副本，他们认为这是“完成工作的最简单方法”。 这里的现实情况是，除非您确定这是真的需要，否则您基本上只是在为您的开发过程和任何部署增加开销，每次更改基于GAC的程序集时，您都必须对整个机器进行回归测试，以防GAC更改影响到一些意想不到的事情（您是否为每个应用程序使用该版本的程序集）

您将得到大量的配置文件，这些文件指定程序集绑定重定向到您所关心的所有版本，而实际上更好的选择是部署一个“构建”，并包含所有依赖项的当前构建版本，这是避免Java人员所知的“dll地狱”的一种非常好的方法（从来没有一个完整的依赖网络的正确版本）

简言之： 只需构建/购买一个ECM，并提供一个“可插拔”模型，允许您在不需要任何形式部署的更改的情况下尽可能满足客户的需求

在我的例子中，我构建了一个系统，允许通过工具或配置生成一定数量的代码，从而在已知的函数树中产生不同的行为。

您的情况（我的解释）

听起来您的情况是ECM（企业内容管理）。 在这种情况下，您基本上需要一个