Zend 框架的多租户
只是好奇人们如何使用 Zend 处理多租户（特别是目录结构、数据库、模块化、每个租户视图等）。我自己还没有发现太多，有人吗？
Just curious as to how people are tackling multi tenancy using Zend (particularly directory structure, database, modularity, per tenant views, etc.). I haven't found too much myself, anyone?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这需要一些工作，但它是可行的。我不确定我的方法在多大程度上遵循多租户的最严格定义，但如果它给您一些想法：
我安装了一个应用程序，它很大程度上遵循推荐的项目结构（http://framework.zend.com/manual/en/project-struct.project.html）。然后，我使用该应用程序为每个站点创建一个 ZF 应用程序。它们每个都包含一个到主应用程序的符号链接（当前位于库文件夹中，尽管这可能会改变）。每个站点应用程序都使用主应用程序的引导程序类，但它们有自己的配置文件。
该应用程序包含大量模块，每个模块可能在每个站点上启用，也可能不启用。我在引导程序中有一个 _initModules() 方法，它查询数据库以找出应该启用哪些模块。然后以正常方式引导它们。
可以向 Zend_View 添加额外的视图路径（按顺序检查），因此站点将其自己的视图路径添加到堆栈中。通过这种方式，站点可以轻松覆盖主应用程序中的视图。还可以将特定于站点的模型目录添加到 include_path，这将允许站点覆盖应用程序模型，尽管我还没有发现需要这样做（并且可能会对性能产生影响）。
It takes a little work, but it's doable. I'm not sure how much my approach follows the strictest definition of multi-tenancy, but in case it gives you some ideas:
I have one installation of my application, which largely follows the recommended project structure (http://framework.zend.com/manual/en/project-structure.project.html). I then have one ZF app per site using the application. These each include a symlink to the main application (currently in the library folder, although this may change). The site apps each use the main application's bootstrap class, but they have their own config files.
The application includes a large number of modules, each of which may or may not be enabled on each site. I have an _initModules() method in the bootstrap which queries the database to work out which modules should be enabled. These are then bootstrapped in the normal way.
It's possible to add additional view paths (which are checked in order) to Zend_View, so a site adds its own view path to the stack. This way sites can easily override views that are in the main application. It would also be possible to add a site-specific model directory to the include_path, which would allow sites to override application models, although I haven't found a need for this yet (and there would likely be a performance impact).