与小型专用 PHP 脚本相比,整体 PHP 编码有哪些优点/缺点?
我曾经使用过单一的 PHP 编码方法。
也就是说,我编写一个index.php,平均大小为70k-250k,并使用
mod_rewrite
将其余部分转换为
REQUEST_URI
传递到index.php的参数来控制正在发生的事情。
另一种方法是编写许多小型 php 脚本,每个脚本专门用于特定目的。我认为我的一些更活跃的 ajax 脚本可能会从中受益。
让我陷入这个思考过程的一件事是我不知道使用包含,特别是条件包含会如何影响操作码缓存的性能。
由于我对此的偏执,如果可能的话,我通常会完全避免包含,但这会导致重复代码或保持单一。
由于我无论如何都使用 mod_rewrite,因此两种方法之间的转换应该很简单。
我期待您的评论。
编辑:我的目标应用程序之一目前每秒处理 80-100 次页面点击(我有一些不错的硬件)。其中大部分是ajax 请求。一切都很有效并且很敏捷,但我已经作为一名 php 程序员进行了开发,没有批评并且需要它。
I have historically used a monolithic approach to PHP coding.
That is, I write one index.php, with an average size of 70k-250k, and use
mod_rewrite
to turn the rest of the
REQUEST_URI
into parameters passed into the index.php to control what is happening.
The alternative would be to write many small php scripts, each specialized to a particular purpose. I'm thinking that some of my more active ajax scripts may benefit from this.
One thing that has kept me in this thought process is I don't know how using includes, especially conditional includes would affect the performance of the opcode cache.
I have generally avoided includes altogether if possible due to my paranoia about this, but this results in either duplicating code, or staying monolithic.
As I'm using mod_rewrite anyway, converting between the two methodologies should be simple.
I look forward to your comments.
EDIT: One of my target apps currently handles 80-100 page hits per second (I got some decent hardware). Most of those are ajax requests. Everything works and is snappy, but I've developed as a php programmer without critique and need it.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
使用包含文件维护和调试大型应用程序的便利性远远超过了不使用包含文件所带来的性能优势。
返工是浪费。将代码从一个应用程序复制并粘贴到另一个应用程序是维护地狱。
The performance bonuses of not using included files is far outweighed by the ease of maintaining and debugging a large application using included files.
Rework is waste. Copying and pasting code from one app to another is maintenance hell.
除了其他评论(我完全同意)之外,还有另一种观点:我的经验是,如果走极端,单一方法会消耗宝贵的 RAM - 必须加载整个文件才能解释,无论是否其中的所有内容是否需要,仅此一项就消耗了每个实例获得的 8、16 或 32 MB 的大量空间。
In addition to the other comments (with which I agree completely), another view: I have made the experience that a monolithic approach, if driven to extremes, costs valuable RAM - the whole file has to be loaded to be interpreted, no matter whether everything from it is needed or not, and that alone eats off a lot from the 8, 16, or 32 MB you get per instance.
请不要忘记测试和维护代码。我无法想象您是否能够将单元测试写入仅在单个文件中的项目。此外,很难预测哪些功能可能会被您刚刚所做的更改破坏。在模块化架构的情况下,如果您更改某个模块,那么您只能破坏该模块和依赖于它的模块。即使是很小的更改对于单个文件项目也可能是致命的(您可能忘记关闭引用,这会立即破坏所有页面)。我认为即使我们做了很小的更改,您也必须重新测试所有功能。这对于测试人员来说可能是一种痛苦,特别是您无法使用单元测试。
另外,如果我将所有代码存储在一个文件中,那么您很可能会得到一个错误的代码。这样的代码会让你倾向于使用全局变量。在这种情况下,很难在其他项目中重用此类代码。当然,你可以复制它,但请记住,当你复制某些东西时,你就复制了它的所有错误。想象一下您可以使用一组经过良好测试(感谢单元测试)库的项目。当新的错误出现时,它只是在一个地方被修复。
另一件事是,当您在团队中使用单个文件工作时会很痛苦。即使只有 2 名开发人员,他们也会浪费大量时间来合并更改。
无论如何,如果您的项目一点也不大,您可以使用单文件 appoch。
Please don't forget about testing and maintaining the code. I can't image if you're able to write unit-tests to a project which is just in single file. Futher more, it's much harded to predict which functionality can be broken by changes you've just made. In case of modular architecture if you change some module then you can only break this module and modules which depends on it. Even a small changes can be fatal to single file projects (you can forget to close quote which will break all pages at once). I think you must retest all the functionality after even small changes we've made. And this can be a pain for testers ecpecialy you're not able to use unit-tests.
Also if all code i stored in a single file then you'll more likely have a bad code. Such code will tend you to use global variables. In this case it's hard to reuse such code in other project. Of cause you can copy it, but remember when you copy something you copy all its bugs. Just imagane the project where you can use set of well-tested (tell thanks to unit-tests) libraries. When new bug appear then it's just fixed in a single place.
One more thing, when you're working in a team using a single file will be pain. Even if there is only 2 developers they waste much time to merge changes.
Any way, if your project is not big at all you can use single file appoch.
对于 Unix 命令行脚本来说,整体方法允许非常高水平的可移植性。
使用单个(hashbang)脚本甚至允许将脚本转储到
usr/bin
中这允许从任何地方、任何路径调用程序,只需键入
myprog
,而不是/PATH/./myprog
。确保它可以被信任!我们必须格外小心路径。
关于路径的一些简单示例:
处理 POSIX SIGNALS
这并不意味着我们必须将所有内容写入一个块中,但将渲染合并到一个文件中,从而允许在 Unix 环境中使用许多额外的功能。
有很多话要说,php 作为 cli 脚本是一个神奇的野兽。
For Unix command line scripting, the monolithic approach allow a very high level of portability.
Using a single (hashbang) script even allow to dump the script in
usr/bin
This allow to call the program from anywhere, any path, by just typing
myprog
, instead of/PATH/./myprog
. Make sure it can be trusted!We have to take an extra care of the paths.
Some simple examples about paths:
Handle POSIX SIGNALS
This doesn't mean we have to write everything in one block, but merge the rendering in one file allow many extra capabilities in a unix env.
There is a lot to say, php as cli script is an amazing beast.
模块化代码更容易理解和维护。巨大的整体代码库可能会变得像纸牌屋一样。它在实践中工作得很好,但改变任何较低的元素都是不可能的。如果您将代码分成清晰的抽象,那么进行更改就会容易得多,并且如果您添加开发人员,您将避免一场噩梦。
Modular code is easier to understand and maintain. A huge monolithic codebase can become like a house of cards. It works just fine in practice, but changing any of the lower elements becomes impossible. If you split up your code into clear abstractions, it can be much easier to make changes and you'll save yourself a nightmare if you ever add developers.