我应该为多个站点使用一个框架代码库还是为每个站点使用一个框架代码库？
情况是这样的：
- 使用某种框架构建多个站点。
- 所有站点都托管在同一服务器上。
- 每个站点都有自己的数据库，
由于所有站点都托管在同一位置，并且它们都具有共同的框架代码，因此我可以轻松地在服务器上安装框架一次，并让每个站点使用相同的文件作为其框架代码。 这样我就只有 1 个可供所有网站使用的框架安装。
第二种选择是让每个站点都使用自己的框架安装。
选项 1 的优点和缺点：
- 只需为多个网站的框架维护 1 个代码库
- 框架更新立即适用于所有网站
- 如果 1 个网站对框架有不同的需求或具有不再与最新框架版本兼容的代码，请自定义需要框架兼容性补丁。 （并不总是有时间或预算来保持遗留项目与最新框架版本兼容）
选项 2 的优点和缺点：
- 每个站点都有单独的框架来维护
- 必须为每个站点单独应用框架更新
- 如果 1 个站点有不同的需求框架或没有预算与最新的框架更新兼容，我们根本不更新该网站的框架安装。
- 如果确实有必要，站点可以快速修改其框架以满足需要，而不会干扰服务器上的其他站点。
因此，选项 1 似乎更容易维护，而选项 2 则更加灵活。我不知道什么是最重要的。 总体而言，这 2 个选项中哪一个是最佳选择？或者还有更多可能的选择吗？
Here's the situation:
- Multiple sites are built using a certain framework.
- All sites are hosted on the same server.
- Each site has its own database
Since all the sites are hosted on the same location and they all have the framework code in common, I could easely install the framework once on the server and have each site use the same files as their framework code.
This way I only have 1 framework installation that is used by all the websites.
The second option is to have each site work with its own installation of the framework.
pro's and con's of option 1:
- Only have to maintain 1 codebase for the framework of multiple websites
- Framework updates instantly apply for all the websites
- Should 1 site have different needs of the framework or have code that's no longer compatible with the latest framework version, custom framework compatibility patches become required. (there is not always time or budget to keep legacy projects compatible with the latest framework version)
pro's and con's of option 2:
- Seperate framework for each site to maintain
- Framework updates have to be applied seperately for each site
- Should 1 site have different needs of the framework or has no budget to be maid compatible with the latest framework update, we simply don't update that site's framework installation.
- If it's really necessary, a site could quickly modify its framework to match the needs without interfering with other sites on the server.
So option 1 seems easier to maintain, while option 2 is much more flexible. I don't know what's most important.
Which of the 2 options is the overall the best choice? Or are there more options possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的做法略有不同。
我有一个像这样的目录结构：
然后在每个站点内都有一个 /framework 映射，它指向该站点正在使用的框架的版本。这样，每个站点的框架版本都独立于其他站点：如果一个站点需要与其他站点不同的框架版本（坚持使用旧版本，在其他站点进行测试之前需要新版本），那么您可以控制那种粒度。同样，更改
/framwork/nightly/中的代码库（例如）将“自动”更新所有站点，其 /framework 映射指向该代码库的前沿版本。I approach this slightly differently.
I'd have a dir structure like this:
Then within each site have a /framework mapping which points to the version of the framework that site is using. That way each site's framework version is independent of the others: if one site needs a different framework version than the others (stuck on an old version, needs a new version before the other sites have been tested with it), then you have control over that sort of granularity. Equally, changing the codebase in
/framwork/nightly/(for example) will "automatically" update all sites with their /framework mapping pointing to that bleeding-edge version of the codebase.就我个人而言，我将始终让每个站点使用自己的框架代码库，或者至少使用冻结在设定版本的共享代码库。共享框架的问题在于，每次更新时，您都必须使用共享代码库测试每个站点，以确保它们仍然按预期工作。当框架弃用您在站点之一中使用的功能时，还会发生什么情况？它可能会阻止您更新，从而导致安全问题。
选项 2 确实会给您带来更多的维护开销，但我认为这是最安全的方法。
Personally, I will always have each site using its own framework codebase, or at least using a shared codebase frozen at a set version. The problem with sharing the framework is that with each update, you'd have to test each site using that shared codebase to ensure they are still working as expected. What also happens when the framework deprecates a feature you use in one of your sites? It could prevent you from updating, leaving you open to security issues.
Option 2 does give you more of a maintenance overhead but it's the safest approach in my opinion.
这取决于几个因素。
有多少开发人员在这些网站上工作？该框架是否得到良好的支持和记录？是否有更好的框架可用（通过文档、开销（内存占用）和社区支持更好）。哪种选择在 12 个月或更长时间后看起来会更好。
选择 1 因其一致性和熟悉性而具有吸引力。
选择 2 因其潜力、学习和未来成长而有吸引力。
It depends on a couple factors.
How many developers working on the sites? Is the framework well supported, documented? Is there a *better framework available (better by documentation, overhead (memory footprint) and community support). Which choice would look better 12 months or longer down the road.
Choice 1 is appealing for its consistency and familiarity.
Choice 2 is appealing for its potential, learning and future growth.