大型PHP应用程序设计问题 [英] Large Scale PHP Application Design Questions
问题描述
我即将开始在我的第一个大型网站上工作（在我看来）
希望每天有1000多个用户。好吧，这不是google / facebook
规模，但它会比家人和朋友更多点击。
无论哪种方式，我都计划在这个网站上爆炸，因为我有足够的
功能集，所以我很关心长期的性能和可扩展性
run。
我曾在一家软件公司工作，但我从来没有专业编程PHP
（寻找入门级工作） ，wink wink）。
我想知道Sitepoint，MySpace，Facebook等网站是否真的使用数据库抽象层和模板引擎。
我还打算为我的投资组合使用这个网站的代码，所以我想
有尽可能多的原始代码，这就是为什么我甚至没有考虑使用一个框架（我已经和CakePHP和ZF讨论过一些）的b $ b，所以我不会赞成
打扰询问使用它们进行大规模的比赛电子网站。
我一直在做很多研究，在我看来，使用PHP作为一个模板引擎本身并创建我的模板使用本机数据库调用自己的数据库类
（使用MySQL直到我发现它不再满足我的需求）将是
最有效的方法。
我计划分离数据/业务/演示逻辑以便维护
更容易，所以这是我考虑使用模板引擎<的唯一原因br />
将业务/表示层分开，然后分离PDO，ADOdb或
PEAR :: DB作为数据层。
但是，我再次得出结论，使用纯PHP将商业/演示层分开，而使用我自己的自制DB类作为
关于
性能/可扩展性的数据层将是最好的方式。
是否有专业人士在那里工作l大规模
可以借给他们两美分的网站/应用程序？
Jesse Burns写道：
< blockquote class =post_quotes>
我即将开始在我的第一个大型网站上工作（在我看来）
希望每天有1000多个用户。好吧，这不是google / facebook
规模，但它会比家人和朋友更多点击。
无论哪种方式，我都计划在这个网站上爆炸，因为我有足够的
功能集，所以我很关心长期的性能和可扩展性
run。
我曾在一家软件公司工作，但我从来没有专业编程PHP
（寻找入门级工作） ，wink wink）。
我想知道Sitepoint，MySpace，Facebook等网站是否真的使用数据库抽象层和模板引擎。
我还打算为我的投资组合使用这个网站的代码，所以我想
有尽可能多的原始代码，这就是为什么我甚至没有考虑使用一个框架（我已经和CakePHP和ZF讨论过一些）的b $ b，所以我不会赞成
打扰询问是否将它们用于大规模的si测试。
我一直在做很多研究，在我看来，使用PHP作为一个模板引擎本身并创建自己的模板使用本机数据库调用的数据库类
（在我发现它不再满足我的需求之前使用MySQL）将是
最有效的方法。
我计划分离数据/业务/演示逻辑以便维护
更容易，所以这是我考虑使用模板引擎的唯一原因/>
将业务/表示层分开，然后分离PDO，ADOdb或
PEAR :: DB作为数据层。
但是再一次，我得出的结论是，使用纯PHP将商业/表达层分开，而使用我自己的自制数据库类作为
数据关于
性能/可扩展性，这将是最佳方式。
是否有专业人士在大型sca工作le $ / $
网站/应用程序可以借给他们两美分吗？
在成为问题之前不要担心性能。 1000名访客
每天都没有。
设计一个好的网站并使用良好的编程习惯。诸如
模板引擎之类的东西都有它们的用途 - 主要是在快速开发中。他们
不一定要让维护变得更容易或更难。
但是，这可能不是你最好的网站。
-
==================
删除x表示x。来自我的电子邮件地址
Jerry Stuckle
JDS计算机培训公司
js ******* @ attglobal.net
==================
第一次不要指望一切正常。在我自己学习一个
大项目（因为我学习PHP）我反复不得不回去和
当我遇到路障或潜在的时候重新编码已完成的部分< br $>
设计缺陷。
如果它的东西会增长，请尽早了解如何
组织你的文件和展示你的页面 - 部分是为了安全
部分是为了理智。
为变量，字段和函数命名（我使用：table_field
适用于所有数据库字段，局部变量也非常具有描述性。
格式化代码（PEAR格式化提示是一个很好的开始）。
为POST，GET和DB输入/输出调用设置函数库
（几乎任何其他重复的东西）所以你只有一个
随着你的进步改进数据过滤的地方。
找到并使用一个好的IDE（我在Linux上使用Quanta）它确实很多
很棒的东西，比如项目全搜索 - 替换。
此外，PHPMyAdmin是进行MySQL开发工作的最佳实用工具，
（你仍然应该知道如何从MYSQLprompt /和
直接调用）PHPMyAdmin让MySQL的工作变得更快。
10月17日，03：36，Jesse Burns。 < jburns ... @ jbwebware.comwrote：
我即将开始在我的第一个大型网站上工作（在我看来）
有望每天拥有1000多名用户。好吧，这不是google / facebook
的规模，但它会比家人和朋友更多点击。
这不是一个巨大的数量。
>
我想知道Sitepoint，MySpace，Facebook等网站是否等等...实际上
使用数据库抽象层和模板引擎。
我还打算为我的投资组合使用该网站的代码，所以我'我希望
拥有尽可能多的原始代码，这就是为什么我甚至没有考虑使用框架来计算
（我已经涉足过有点像CakePHP和ZF），所以我不会想要把它们用于大型网站。
我一直在做很多研究，在我看来，使用PHP作为一个模板引擎本身并使用原生数据库调用创建我自己的数据库类
（将使用MySQL直到我发现它不再满足我的需求）将是
最有效的方法。
我计划分离数据/业务/演示逻辑以进行维护
更容易，这是'我考虑使用模板引擎来分开商业/演示层，然后是PDO，ADOdb或
PEAR的唯一原因:: DB用于数据层。
但是我再次得出结论，使用纯PHP分离商业/演示文稿
层，虽然使用我自己的自制DB类作为
，数据层将是关于
性能/可扩展性的最佳方式。
是否有专业人士在那里有大规模工作的经验
网站/应用可以借给他们两美分？
在开始编写代码之前考虑版本控制 - 从长远来看，它会让生活变得简单得多。同样计划测试
- 我建议进行持续的集成测试，因为
必须具备和单元测试一样好。
在任何地方使用抽象都是在生产力和性能之间进行权衡 - 具有抽象层的IME并没有真正使得跨越DBMS的代码可以移植。我不是纯粹的ORM的粉丝，而是封装了作为对象的
数据源（使用工厂模式）可以使可移植性更加轻松，并且可以实现更好的代码管理。
正如拉里所说，坚持一个好的，标准的风格指南。文件
您的代码正确 - 并找到适合您的代码文档工具
（PHPDocumentor，PHPXRef ....）。
将您的公共代码构造为包含在
include_path中的目录中，并始终使用相对路径包含/ require
到此目录。
在进行数据库设计时 - 不要使用自动增量ID - 这个
关闭了许多路径上的门，用于扩展你的应用程序
a单个DBMS（如果没有内部密钥，则使用序列号和存储库标识符（例如，
数据库主机名）。
获取DNS从您的托管中单独注册 - 如果您将它们绑定到同一供应商那么他们可能最终会被扣为人质，如果您确实打了很大的时间。
我一直遵循的指导原则是避免在任何需要的地方编写代码 - 其中包括
很多优质的PHP代码已经发布了
并且可以免费使用 - 遗憾的是它相当于一个非常小的数额
到错误的PHP代码量。你会在这里得到很多意见
。
HTH
C.
I''m about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn''t on the google/facebook
scale, but it''s going to be have more hits than just family and friends.
Either way, I''m planning on this site blowing up once I have enough of a
feature set, so I''m concerned about performance and scalability in the long
run.
I''ve worked for a software company, but I''ve never programmed PHP
professionally (looking for an entry level job, wink wink ).
I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.
I also plan on using the code for this site for my portfolio, so I''d like to
have as much original code as possible, that''s why I''m not even considering
using a framework (I''ve dabbled a bit with CakePHP and ZF), so I won''t
bother asking about using them for large scale sites.
I''ve been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.
I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that''s the only reason I''m considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.
But once again, I''ve come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.
Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?
Jesse Burns wrote:I''m about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn''t on the google/facebook
scale, but it''s going to be have more hits than just family and friends.
Either way, I''m planning on this site blowing up once I have enough of a
feature set, so I''m concerned about performance and scalability in the long
run.
I''ve worked for a software company, but I''ve never programmed PHP
professionally (looking for an entry level job, wink wink ).
I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.
I also plan on using the code for this site for my portfolio, so I''d like to
have as much original code as possible, that''s why I''m not even considering
using a framework (I''ve dabbled a bit with CakePHP and ZF), so I won''t
bother asking about using them for large scale sites.
I''ve been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.
I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that''s the only reason I''m considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.
But once again, I''ve come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.
Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?
Don''t worry about performance until it becomes a problem. 1000 visitors
a day is nothing.
Design a good site and use good programming practices. Things like
templating engines have their use - mostly in rapid development. They
don''t necessarily make maintenance any easier or harder.
But also, this may not be the best site for you to cut your teeth on.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Don''t expect everything to go just right the first time. Working on a
big project myself (as I learn PHP) I''ve repeatedly had to go back and
recode finished sections when I ran into a roadblock or potential
design flaw.
If its something that''s going to grow, look early-on into how to
organize your files and present your page(s) - partly for security
partly for sanity.
Name your variables, fields, and functions well ( I use: table_field
for all DB fields, and local variables are pretty descriptive too)
Format your code (the PEAR formatting tips are an excellent start).
Setup function libraries for your POST, GET, and DB input/output calls
(just about anything else that gets repeated) so you have just one
place to refine data filtering as you progress.
Find and use a good IDE (I use Quanta on Linux) it does sooo many
great things like project-wide search-replace.
Also PHPMyAdmin is THE BEST utility for doing MySQL development work,
(you should still know how to do MySQL from the MYSQLprompt/ and
direct calls) PHPMyAdmin just makes MySQL work go so much quicker.
On 17 Oct, 03:36, "Jesse Burns" <jburns...@jbwebware.comwrote:I''m about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn''t on the google/facebook
scale, but it''s going to be have more hits than just family and friends.
This is not a huge volume.
>
I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.
I also plan on using the code for this site for my portfolio, so I''d like to
have as much original code as possible, that''s why I''m not even considering
using a framework (I''ve dabbled a bit with CakePHP and ZF), so I won''t
bother asking about using them for large scale sites.
I''ve been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.
I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that''s the only reason I''m considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.
But once again, I''ve come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.
Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?Think about version control before you start writing the code - it''ll
make life a lot simpler in the long run. Similarly plan the testing
ahead - I''d recommend going for continious integration testing as a
must have and unit testing as a nice to have.
Using abstraction anywhere is a trade-off between productivity and
performance - IME having an abstraction layer does not really make
code portable across DBMS. I''m not a fan of pure ORM but encapsulating
data sources as objects (using a factory pattern) can make portability
less painful and make for better code management.
As Larry suggests, stick to a good, standard style guide. Document
your code properly - and find a code document tool which suits you
(PHPDocumentor, PHPXRef....).
Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.
When doing your database design - don''t use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).
Get your DNS registration seperately from your hosting - if you tie
them both to the same supplier you could end up being held hostage by
their provision plans if you really do hit the big time.
The guideline I''ve always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You''ll always get lots of opinions
here.
HTH
C.
这篇关于大型PHP应用程序设计问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
