PHP Bootstrap 更好的方法？

发布于 2024-07-12 13:08:17 字数 683 浏览 11 评论 0原文

引导 PHP 应用程序是一个好习惯吗？我找到了两种引导 PHP 应用程序的方法。需要一些建议，这是更好的方法。

第一。
为文件夹结构定义常量

$controllerPath = 'controller';
define('CONTROLLER', str_replace('\\', '/', realpath($controllerPath)).'/');

//usage
require_once CONTROLLER . 'somecontroller.php';

第二
使用 ini_set 设置应用程序根目录的包含路径

$rootPath = $_SERVER['DOCUMENT_ROOT'];
$includePath = ini_get('include_path');
ini_set('include_path', '.'.PATH_SEPARATOR.$rootPath.PATH_SEPARATOR.$includePath);

//usage
require_once 'controller/somecontroller.php';

请告诉我哪种方法更好。

如果是高负载应用程序，哪一个是最好的方法？

原文

Is it a good practice to bootstrap your PHP application.
I found two ways to bootstrap my PHP application. Need some suggestions which is a better way.

First.
Define a constant for the folder structures

$controllerPath = 'controller';
define('CONTROLLER', str_replace('\\', '/', realpath($controllerPath)).'/');

//usage
require_once CONTROLLER . 'somecontroller.php';

Second
Using ini_set set the include path to the application root

$rootPath = $_SERVER['DOCUMENT_ROOT'];
$includePath = ini_get('include_path');
ini_set('include_path', '.'.PATH_SEPARATOR.$rootPath.PATH_SEPARATOR.$includePath);

//usage
require_once 'controller/somecontroller.php';

Please tell me which is a better way.

In case of a high-load application which would be the best method ??

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

浅紫色的梦幻 2024-07-19 13:08:17

使用 ini_set 将其设置为应用程序上方的目录。这就是为什么您可以在 require 语句中使用文字字符串。此外，它使重用代码的使用变得更加容易。

require 'coolapp/class/Model.php'
require 'coolapp/display/Router.php'
require 'spinoff/display/JsView.php'
// etc

它类似于 java 中完全限定导入 com.whatever.app.more 的想法，或者在 python 中所有应用程序导入应该如何绝对关于该应用程序。

回复：高负载应用程序

除非您要加载数千个文件，否则包含文件所需的时间可能不是瓶颈。但是，如果是这种情况，您有几个选择。一种是APC，它将include的结果缓存在内存中。另一种方法是从单个文件加载所有内容，类似于如何将 javascript 文件串联成一个文件以获得更好的性能（巧合的是，APC 有一个函数可以为您提供此信息）。 APC 确实易于设置且完全透明，可提升约 50% 的性能提升。

Use ini_set to set it to the directory -above- your application. That why you can use the literal strings in your require statements. In addition, it makes it easier to use reuse code

require 'coolapp/class/Model.php'
require 'coolapp/display/Router.php'
require 'spinoff/display/JsView.php'
// etc

Its similar to the idea in java of having fully qualified imports of com.whatever.app.more, or how in python all of an apps imports should be absolute with respect to that app.

Re: High load application

Unless you are loading many thousand files, the time it takes to include files probably isn't a bottle neck. But, if it was the case you have a couple options. One is APC, which caches the results of include in memory. Another is to load everything from a single file, similar to how javascript files are concatenated into one for better performance (coincidentally, APC has a function that gives you this information). APC is really easy to setup and is completely transparent, for a boost of ~50% better performance.

回复收藏 0 原文

自此以后，行同陌路 2024-07-19 13:08:17

最好使用绝对路径，而不是让 PHP 在给定的包含路径之一中查找文件。

因此，我倾向于第一种方法，使用一个常量来保存应用程序根目录的绝对路径。

回复收藏 0 原文

猫九 2024-07-19 13:08:17

这就是我所做的：

将 /include 目录放在文档根目录（或任何你想称呼的名称）的顶部，用于存放所有类、辅助函数等；
使用 mod_rewrite 使 /include 目录不被提供服务；
那里有一个名为 setup.php 的文件，它设置相关的 ini 参数、路径等；
该文件通过相对路径包含在每个页面中；然后
其他一切都可以依赖它创建的设置。

顶级 .htaccess 的重写规则示例：

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /include/
RewriteRule ^include/ - [R=404,L]

我可能略有偏差。我手头没有标准规则。您会注意到，这是我创建的 404 错误，而不是 403（禁止）。这是故意的。当您登录系统时，它不会显示“未知用户”或“密码不正确”，因为这会告诉您一些信息。我宁愿假装根本没有 /include 目录，也不愿说它在那里，但你就是看不到它。

此时，您可以设置所需的所有内容，以便其余代码可以执行以下操作：

require 'Class.php';

甚至定义一个 __autoload() 以便它自动发生。

This is what I do:

Put an /include directory at the top of your document root (or whatever you want to call it) for all classes, helper functions and so on;
Make it so the /include directory isn't served by using mod_rewrite;
Have a file in there called, say, setup.php, which sets up relevant ini parameters, paths, etc;
Thhat file is included in every page by relative path; and
Everything else can then rely on the settings it has created.

Example rewrite rules for top-level .htaccess:

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /include/
RewriteRule ^include/ - [R=404,L]

I might be off slightly. I don't have my standard rules handy. You'll note that it's a 404 error I create rather than 403 (Forbidden). That's deliberate. When you login to a system it doesn't say "unknown user" or "password incorrect" because that tells you something. I'd rather pretend there was no /include directory at all rather than say it's there but you just can't look at it.

At that point you can setup all you need so the rest of your code can just do:

require 'Class.php';

or even define an __autoload() so it happens automatically.

回复收藏 0 原文

树深时见影 2024-07-19 13:08:17

这是我的引导加载程序的示例：

if (!defined('APPLICATION_PATH')) {
    define('APPLICATION_PATH', realpath(getcwd() . '/../application'));
}

/**
 * Add the APPLICATION_PATH and the library dir to the include_path
 */
set_include_path(get_include_path() . PATH_SEPARATOR . APPLICATION_PATH . PATH_SEPARATOR . realpath(APPLICATION_PATH . '/../library'));

/**
 * Load the file loader to setup the class autoloader
 */
include_once 'Loader.php';
if (!class_exists('Loader')) {
    die('Could not load class loader.');
}

spl_autoload_register('Loader::autoload');

我个人会选择第二种方式。我已经学会了喜欢 include_path：查找大量目录可能会对性能造成一些影响，但我怀疑这会很重要。它还可以防止忘记包含路径常量而发生错误。

附带说明一下，我将控制器等放在 /application/ 中，并在 /library/ 中放置了一些库。这一切都在网络根之上。它完全阻止用户访问这些文件，如果文档根目录下有所有内容，则必须采取预防措施。如果您的主机支持此功能（某些共享主机不支持），请利用它！

更新

如果应用程序负载较高，是否可以使用第二种方法？？

在我看来，如果你要留意 include_path 中的内容（例如，在我的 Windows 开发机器上，我有各种我不需要的东西：SQL Server、Ruby 等）。），如果去掉任何不需要的东西，那么第二种方法就可以了。

您可以做的另一件事是将 include_path 转储到脚本末尾，并将其硬编码到您的 php.ini 文件中。

确实，不过。我认为这不会成为系统性能的瓶颈。使用对您来说更容易的方法。

您正在运行的网站是否存在性能问题，或者这是预防措施？我明白为什么你想要预先优化（我必须阻止自己这样做），但是认真的。当这些问题出现时进行处理。当你幸运地拥有一个受欢迎的网站来处理它时。归根结底，如果您必须替换一些 require，这并不是一场噩梦。

Here's an example of my bootstrap loader:

if (!defined('APPLICATION_PATH')) {
    define('APPLICATION_PATH', realpath(getcwd() . '/../application'));
}

/**
 * Add the APPLICATION_PATH and the library dir to the include_path
 */
set_include_path(get_include_path() . PATH_SEPARATOR . APPLICATION_PATH . PATH_SEPARATOR . realpath(APPLICATION_PATH . '/../library'));

/**
 * Load the file loader to setup the class autoloader
 */
include_once 'Loader.php';
if (!class_exists('Loader')) {
    die('Could not load class loader.');
}

spl_autoload_register('Loader::autoload');

I'd personally go with the second way. I've learned to love the include_path: there is probably some performance hit from looking in lots of directories but I doubt it would be significant. It also prevents errors from forgetting to include the path constant.

On a side note I put my controllers, etc. in /application/, and have some libraries in /library/. This all goes above the web root. It fully prevents users from accessing these files, which you have to otherwise take precautions against if you have everything under the document root. If your host supports this (some shared hosts don't) take advantage of it!

Update

In case of a high-load application is it good to go with the second method ??

In my opinion if you were to keep an eye on what's in your include_path (for example, on my Windows dev machine I have all sorts in there that I don't need: SQL Server, Ruby etc.) and were to strip out anything not needed then the second method would be fine.

Another thing you could do is dump the include_path at the end of the script and hard code it into your php.ini file.

Really, though. I don't think this is going to be a bottleneck in your system performance. Use what's easier for you.

Do you have performance issues on a site you're running or is this precautionary stuff? I can see why you'd want to preoptimise (I have to stop myself from doing it) but seriously. Deal with those issues when they arise. When you're in the lucky position of having a popular site deal with it then. At the end of the day, it's not a nightmare if you have to replace a few requires.

回复收藏 0 原文