PHP 开发人员正在寻找与 Java EE 架构等效的解决方案
我是一名 PHP 开发人员，我了解 Java EE 技术，我想用 PHP 以及随之而来的所有技术（MySQL、Apache...）来实现这些技术（n 层、EJB、JPA...）。
I am a PHP developer, I read about Java EE technologies and I want to implement such technologies( n-tier, EJB, JPA...) with PHP and all what coming with (MySQL, Apache...).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不。
PHP 不是 Java。像编写 Java 代码一样编写 PHP 代码是愚蠢并且会适得其反。这很可能会让未来的代码维护者想要伤害你。
需要持久化一个对象吗？ 使用 ORM。
需要多层架构吗？如果您以适当的关注点分离来设计代码，那么您已经完成了 9/10 的工作。
EJB？每次我阅读维基百科文章时，它们的描述都不同。可重复使用的组件？分布式应用程序和数据持久性的标准化接口是什么？是的，很有用，但这不是 PHP。 ORM 和一个好的消息/工作队列将完成工作。
底线：对于绝大多数 PHP 脚本，您不需要任何“企业技术”。如果您这样做，那么您就做错了：要么您对应用程序进行了过度架构，要么您选择了错误的平台。
首先选择现代 PHP 框架< /a>，然后从那里构建您的应用程序。如果您来自 Java，那么 Zend Framework 看起来是最不陌生的。 Kohana、Symfony 和 CodeIgniter 都值得。现在避免蛋糕。
保持简单，这样就不会出错。
Don't.
PHP is not Java. Writing PHP code like you'd write Java code is silly and counterproductive. It's very likely to make future maintainers of the code want to hurt you.
Need to persist an object? Use an ORM.
Need a multi-tier architecture? If you design your code with proper separation of concerns, you've already gotten 9/10ths of the way there.
EJBs? Every time I read the Wikipedia article, they're described differently. Reusable components? With a standardized interface for what, distributed applications and data persistence? Useful, yeah, but that's not PHP. ORMs and a a good message/work queue will get the job done.
The bottom line: For the vast majority of PHP scripts, you will not need any "enterprise technologies." If you do, you're doing something wrong: either you've having overarchitected the application, or you've chosen the wrong platform.
Start by picking a modern PHP framework, and build your application from there. If you're coming from Java, then Zend Framework will seem the least foreign. Kohana, Symfony and CodeIgniter are all worthwhile. Avoid Cake for now.
Keep it simple and you can't go wrong.
你的问题很有洞察力。这是因为，随着您的企业变得更加成功，它必须扩大以支持更多流量的负载。因此，您必须将 PHP 代码分成层，并在单独的层（单独的服务器或单独的虚拟机，如 Xen）上运行。
例如，我设计了一个系统去年在运行大约 25 个 Xen 虚拟机 (VM) 的 10 个 Linux OpenSUSE 服务器上用 PHP 实现。其中一些 VM 是负载平衡器，一些是前端层，一些是中间层，一些是后端层，一些包含 MySQL 数据库，我们有几个专用服务器，它们是用于用户文件存储的 RAID 阵列。我们根据需要创建了 NFS 挂载，以便将文件保存到 RAID 阵列或从 RAID 阵列读取文件。
我们将这些层分为三个相关组，因此我们可以为 QA、Staging（用户验收）和生产拥有独立的测试站点。
因此，我们的 PHP 软件被分为松散耦合的层，如下所示：
前端层 (VM)
包括 AJAX 响应、验证
代码、导航等
包括管理仪表板
访问系统指标和单元测试工具
RESTful Web 服务 API（带令牌）
为合作伙伴提供服务并
其他使用该系统作为
“平台。”
中间层 (VM)
具体到系统或业务，
或角色和权限
互操作层的各种用例
授权并发布到社交媒体
网络或合作伙伴应用程序，
数据
后端层 (VM)
查询、插入、更新、删除
数据库（实现为Prepared
陈述）以一种可以的方式
当数据库更改为时进行调整
另一种...示例：来自
PostgreSQL 到 MySQL，反之亦然。
包括用于备份和的 PHP 代码
恢复数据库。
另一位受访者提出的使用企业软件框架的想法对我来说似乎很愚蠢。如果您正在单个服务器上开发学生项目或“概念验证”，并且您已经熟悉框架，那么它可能可用于快速原型设计。
但正如您从上面看到的，当您编写跨多个层分布的生产质量代码时，您不需要使用框架的拐杖。
您会将框架放在哪里以链接到代码中的所有位置？在每一层？坏主意。框架包含许多您可能需要也可能不需要的页面。因此，它们会降低性能，尤其是当乘以必须安装它们的每一层时。
同样低效的是创建一个“层”来包含每个其他层都必须调用的框架。软件层的好处是松耦合且独立于其他层，这样当某一层发生变化时，不需要另一层发生变化。
此外，编写生产质量代码的开发人员不需要依赖框架所代表的“瑞士军刀”。这些开发人员非常有能力编写有针对性的高效代码，并且在必要时重用他们可能为以前的项目开发的库中的类。
Your question is an insightful one. That's because as your enterprise becomes more successful, it will have to scale up to support the load of more traffic. So you will have to separate your PHP code into layers that run on separate tiers (either separate servers or separate Virtual Machines like with Xen.)
For example, I designed a system last year implemented in PHP on 10 Linux OpenSUSE servers running about 25 Xen Virtual Machines (VMs.) Some of the VM's were load balancers, some were front end tiers, some were middle tiers and some were back-end tiers, some contained MySQL databases, and we had a couple of dedicated servers that were RAID arrays for user file storage. We created NFS mounts as necessary to save/read files to/from the RAID array.
We grouped the tiers into three related groups, so we could have independent test sites for QA, Staging (User Acceptance) and Production.
So our PHP software was separated into loosely-coupled layers as follows:
FRONT-END TIER (VMs)
including AJAX responses, validation
code, navigation, etc.
including Admin Dashboard with
access to system metrics and Unit Test harnesses
RESTful Web Services API (with token)
to provide services to Partners and
others who use the system as a
"platform."
MIDDLE TIER (VMs)
specific to the system or business,
or the roles and permissions for
various use cases
authorizations and posts to Social
networks or Partner applications,
etc.
BACK-END TIER (VMs)
queries, inserts, updates, deletes to
the database (implemented as Prepared
Statements) in a way that can be
adapted when the database changes to
a different kind...example: from
PostgreSQL to MySQL or vice versa.
Includes PHP code for backing up and
restoring databases.
The idea another respondent brought up of using a Framework for enterprise software seem pretty silly to me. If you are developing a student project or a “proof of concept” on a single server, and if you already are familiar with a framework, it may have its use for rapid prototyping.
But as you see from the above, when you are writing Production-quality code, distributed across multiple tiers, you don't need the crutch of using a Framework.
Where would you put the framework to link into all the places in your code? On every tier? Bad idea. Frameworks include many pages that you may need and you may not need. So they slow down performance, especially when multiplied by every tier on which you must install them.
Equally inefficient would be to create a “layer” just to contain a framework that every other layer would have to call. The benefit of software layers is to be loosely-coupled and independent of other layers, so that when changes occur in one layer, they do not require changes in another layer.
Besides, developers who write Production-quality code don't need to rely on a “swiss-army knife” that Frameworks represent. Such developers are quite capable of writing targeted efficient code and, if necessary, reusing classes in a library they may have developed for previous projects.