PHP Zend 框架 - Zend_Config 和全局状态
我正在评估 Zend_Config_Ini 与使用简单常量文件相比的优点。
例如 -
define('DB_HOST',localhost);
//versus
$config = new Zend_Config_Ini('/path/to/config.ini', 'staging');
echo $config->database->params->host; // prints "dev.example.com"
唯一的事情是 $config 不可全局访问。因此，您需要使用 Zend_Registry 来存储以供应用程序使用，而不必每次都启动。
这似乎增加了比需要的更多的复杂性......我是否遗漏了一些东西，或者 Zend_Config + Zend_Registry 是一种从长远来看随着应用程序增长而更好的技术？
I'm in the process of evaluating the benefits of Zend_Config_Ini versus using a simple constant file.
e.g. -
define('DB_HOST',localhost);
//versus
$config = new Zend_Config_Ini('/path/to/config.ini', 'staging');
echo $config->database->params->host; // prints "dev.example.com"
The only thing is that the $config is not globally accessible. So then you need to use Zend_Registry to store for application usage, without having to initiate each time.
This seems to add more complexity than needed.... am I missing something or is Zend_Config + Zend_Registry a technique that is better in the long run as an app grows?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将注册表与配置一起使用的主要优点是避免污染全局命名空间。假设您想要包含第三方库，并且您的应用程序和库都定义了一个常量 DB_HOST。不好。
此外，Zend Framework 中的许多工厂都利用 config 对象来创建实例。
Zend_Db就是一个很好的例子。您只需传递$this->database，它就会获取实例化您的适配器所需的内容。您还可以使用自定义功能扩展注册表，例如查找方法或类似的东西。查看 Fowler 的模式描述。
The main advantage of using the Registry with a config is to avoid polluting the global namespace. Say, you want to include a third party lib and your app and the lib both define a constant DB_HOST. No good.
In addition, many of the factories in Zend Framework utilize the config object to create instances.
Zend_Dbis a good example of this. You just pass it$this->databaseand it will take what it needs to instantiate your adapter.You can also extend the registry with custom functionality, e.g. finder methods or stuff like that. Check the pattern description by Fowler.
Zend_Config的一个很好的优点是您不依赖于“PHP 源代码文件”；只需一个 .ini 文件就可以了——有些人更喜欢修改 .ini 文件而不是 PHP 文件。并且以编程方式修改 .ini/XML 文件更容易 - 有类/函数可以做到这一点！
通过 .ini 文件和
Zend_Config，您还可以获得已经提供的不错的功能；例如，各部分之间的继承（即，您可以有一个“通用”部分，以及覆盖某些值的“暂存”和“生产”）Zend_Config的一个有趣之处是一致性：Zend Framework 和Zend_Application已经假设您将有一个配置文件；那么，为什么不来第二个呢？或者甚至重复使用第一个？框架的几个类也是如此，它们可以使用
Zend_Config的实例来工作或配置；如果你已经有了那个，它会突然变得更容易;-)如果我必须在带有定义的 PHP 文件和 .ini 文件之间进行选择，对于可配置的内容，我可能会选择 .ini 文件（以及
Zend_Config+Zend_Registry需要时）。A nice advantage of
Zend_Configis that you don't depend on a "PHP source code file" ; just a .ini file will do -- and some prefer modifying an .ini file instead of a PHP one.And it's easier to modify an .ini / XML file programatically - there are classes / functions to do that !
With .ini files and
Zend_Config, you also have nice functionnalities already provided ; for instance, inheritance between sections (ie, you can have a "generic" section, and "staging" and "production" that overwrite some values)A thing that can be insteresting about
Zend_Config, too, is consitency : Zend Framework, withZend_Application, already supposes you'll have one configuration file ; so, why not a second one ? Or even re-use the first one ?And it's the same with several classes of the Framework, which can work or be configured with an instance of
Zend_Config; if you already have that one, it suddenly becomes easier ;-)If I had to choose between a PHP file with defines and a .ini file, for things that are configurable, I would probably go with the .ini file (And
Zend_Config+Zend_Registrywhen needed).是的，你是对的，使用 Zend 认可的方法进行配置比定义一系列全局常量更复杂。您获得的优势是
没有全局命名空间冲突
如果您需要将应用程序与另一个项目集成，那么使用全局常量代表您的应用程序配置可能会导致问题。另一个项目拥有名为
DB_HOST的常量的可能性有多大？使用混合系统的开发人员如何判断哪些常量是您的应用程序的配置，哪些是集成应用程序的配置？基于其他人的工作构建
因此，您拥有一个包含所有配置值的文件。您将如何将其部署到不同的环境中？ （生产、登台等）您很可能是一个聪明的人，可以想出一个解决方案，但是进入您的项目的另一个开发人员如何知道该解决方案是如何工作的？应用程序中的其他模块如何知道如何读取全局配置？
Zend_Config已经“解决”了许多问题。通过预先采取更多的复杂性和抽象性，您可以获得已知的前进路径，并且可以花更多的时间来解决应用程序的问题，而不是发明和支持另一个配置系统。Yes, you're correct, using the Zend sanctioned method for configuration is more complex than defining a series of global constants. The advantages you get are
No Global Namespace Collisions
If you ever need to integrate your application with another project, having global constants represent your application config may cause problems. What are the chances another project has a constant named
DB_HOST? How can a developer who's using your hybrid system tell which constants are the config for your application vs. the integrated application?Building on the Work of Others
So, you have a single file with all your config values. How are you going to deploy that into different environments? (production, staging, etc.) Chances are you're a smart person who could come up with a solution, but how is another developer coming into your project going to know how that solution works? How are other modules in your application going to know how to read your global config?
Zend_Confighas already "solved" many of the problems. By taking on a bit more complexity and abstraction up-front you get a known path forward, and can spend more time on solving the problems of your application instead of inventing and supporting Yet Another Configuration System.