我们为多个客户开发了一个门户网站，门户网站之间的差异非常小。 2-3个图像和网站上的可用内容
如果我们要与汽车经销商门户进行比较，一个客户将展示丰田汽车，另一个福特和沃尔沃，另一个丰田和日产，多个站点展示客户选择的汽车。
目前，系统是代码的复制/粘贴版本，并根据需要对代码库进行了更改。经销商品牌形象，联系信息和其他小选项。
网站的核心功能完全相同，按品牌展示汽车，并展示新旧模型。
我们计划重新编写系统，并且Lead想要将数据库调用和页面显示代码放在DLL中并将其注册到GAC。
我试图说服他这个计划，而且它已经落后了。我需要一些实质性的文档来说明为什么在GLS中注册数据库调用和在DLLS中放置代码不是最佳实践，也不是实践。
我创建了两个具有相同代码库的网站，使用HostHeaders调用带有中间件的数据库，根据主机头搜索返回的数据集显示所需的数据。这种方法更容易接受吗？
有没有人尝试过使用GAC？ 如果是这样，您在应用程序的维护周期中遇到了哪些问题？ 使用数据库调用的GAC是否存在任何安全问题？
答案 0 :(得分：2)
您的情况（我的解释）
听起来你的情况就是ECM（企业内容管理）。 在这种情况下，您基本上需要一个核心产品来提供页面，文档，reosurces等，并使用内置于系统中的核心身份验证模型。
这样的系统将是一个支持主题和定制等场景的应用程序（想想wordpress但更多的是“企业”）。
虽然有定制，但实际上它最终是一个核心平台，因此GAC不会让您受益......
When should I deploy my assemblies into the GAC?
... GAC迎合了一个场景，你有一个“Windows平台应用程序套件”，它们共享一些不会发生太大变化的常见“可靠”组件。
关于您的ECM情况
在您的情况下，业务会经常发生变化，因此核心内容的“版本”也会发生变化，最终结果是您的团队需要管理GAC的时间很长，而且随着时间的推移需要大量的GAC以及随之而来的配置文件地狱。
扮演恶魔倡导者（让我假设我错了）
更进一步说，为了完整起见，我说错了，那么你有一种情况，你计划的商业模式每次都涉及每个新客户都有一个“你的产品的新版本”让我们说它是10年之后，你有1,000个客户端，现在需要至少10台服务器，所有这些服务器都有这个GAC管理，并且每个服务器都托管了本质上“部分核心功能配置”的子集。
您的构建和部署过程使用PowerShell进行大量编写，以便在大型服务器场上替换这些基于GAC的核心组件，这需要花费数周时间才能运行并导致大规模中断。
正常的“Web部署”类型方案对您来说不会产生更多麻烦，并且当您想要“迁移到云”时会导致更多问题。
我确实做了一两个假设
我假设有问题的产品至少是基于Web的，但最终基于云并且管理云实例最好通过将应用程序部署到容器而不是服务器（理想模型）来完成。
现在你有一个系统阻止你遵循理想的模型，你必须“取消”你对GAC的依赖，但是对我来说GAC感觉就像.Net提供的遗留功能，为未来服务而不是彻底改变在软件建模方面，目前使用.Net核心的“常见”方法是将.Net本身与应用程序整合在一起并部署到任何平台，其中许多平台可能无法理解GAC的概念。
我的建议
我认为这里真正发生的是你的技术主管关注服务器上的代码重复（或程序集重复），并且正在寻找一种方法去一个地方并管理给定程序集的一个副本被视为“最简单的工作方式”。 这里的实际情况是，除非您确定这是真正需要的，否则您基本上只是增加开发过程和任何部署的开销，每次更改基于GAC的程序集时，如果GAC必须对整个机器进行回归测试更改受影响的事情是不合预期的（天气你使用该版本的程序集或不适用于每个应用程序）。
你最终会得到大量的配置文件，指定程序绑定重定向到你所关心的版本，实际上更好的办法是只使用当前的构建版本部署一个“build”。所有它的依赖关系，这是一个很棒的方法来避免Java家伙所知道的“dll hell”（永远不会拥有完整的依赖网络版本）。
简而言之： 只需构建/购买ECM并提供“可插拔”模型，即可在不需要任何形式部署的情况下尽可能满足客户要求。
在我的情况下，我构建了一个系统，允许通过工具或配置生成一定数量的代码，从而导致已知功能树的不同行为。
答案 1 :(得分：0)
刚愎自用：
来自（“企业”）软件包的“用户”（又名“客户”）“强制” GAC在过去的生活中安装，我就像瘟疫一样远离它
dll地狱”：所以你想使用X的最新更新...但是GAC中的“某些东西”依赖于旧版本的X.
H个