使用 PHP 的多层应用程序？
我对 PHP 比较陌生，但在具有 SOA 架构和多层应用程序的复杂企业环境中经验丰富的 Java 程序员。在那里，我们通常会在中间层实现具有业务逻辑的业务应用程序。
我正在编程一个替代货币系统，该系统应该易于个人和社区部署和定制；它将是开源的。这就是为什么 php/mysql 对我来说似乎是最好的选择。
用户拥有账户，并且获得余额。此外，系统还根据提供的服务总量和可用资产总量来计算价格。
这意味着，在购买时会发生一系列计算；余额和总计得到更新；这些是派生数据，通常不会放入数据库中。
尽管如此，我还是将触发器和存储过程放入数据库中，以便在 php 代码中不会进行任何更新。
人们怎么看？这是一个好方法吗？我的经验告诉我，这不是最好的解决方案，并促使我实施中间层。然而，我什至不知道该怎么做。另一方面，到目前为止我所拥有的商店流程在我看来是最合适的。
我希望我的问题说清楚了。所有评论均表示赞赏。可能没有“完美”的解决方案。
I am relatively new to PHP, but experienced Java programmer in complex enterprise environments with SOA architecture and multitier applications. There, we'd normally implement business applications with business logic on the middle tier.
I am programming an alternative currency system, which should be easy deployable and customizable by individuals and communities; it will be open source. That's why php/mysql seems the best choice for me.
Users have accounts, and they get a balance. also, the system calculates prices depending on total services delivered and total available assets.
This means, on a purchase a series of calculations happen; the balance and the totals get updated; these are derived figures, something normally not put into a database.
Nevertheless, I resorted to putting triggers and stored procedures into the db, so that in the php code none of these updates are made.
What do people think? Is that a good approach? My experience suggests to me that this is not the best solution, and prompts me to implement a middle tier. However, I would not even know how to do that. On the other hand, what I have so far with store procs seems to me the most appropriate.
I hope I made my question clear. All comments appreciated. There might not be a "perfect" solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如当今的趋势一样，远离数据库通常是一件好事。您可以获得更轻松的版本控制，并且只需使用一种语言即可工作。不仅如此，我觉得存储过程是一条很难走的路。另一方面，如果您喜欢这些东西并且对 MySql 中的 SP 感到满意，那么它们还不错，但我的感觉一直是它们更难调试且更难处理。
关于触发器问题，我不确定您的应用程序是否有必要。由于触发计算的事件是由用户调用的，因此即使用户同时被重定向到“等待”页面或另一个页面，这些事情也可能在 PHP 中发生。显然，真正的触发器只能在数据库级别完成，但您可以使用每 X 秒运行一次 PHP 脚本的守护线程...不惜一切代价避免这种情况，并尝试从用户端触发事件。
综上所述，我想在 PHP 上插入我最喜欢的数据访问层解决方案： Doctrine 。它并不完美，但 PHP 本身就足够好了。完成您想要的大部分操作，并让您使用对象而不是数据库过程等。
关于你的头衔，在 PHP 中，多层是完全可行的，但你必须这样做并尊重它们。 PHP 代码可以调用其他 PHP 代码，现在（5.2+）很好地面向对象等等。请务必忽略这样一个事实：您将看到的许多 PHP 代码完全是垃圾，甚至没有使用方法，更不用说层次和像样的 OO 建模了。如果您愿意，一切皆有可能，包括使用您自己的（或使用现有的）MVC 解决方案。
As is the tendency these days, getting away from the DB is generally a good thing. You get easier version control and you get to work in just one language. More than that, I feel that stored procedures are a hard way to go. On the other hand, if you like that stuff and you feel comfortable with SPs in MySql, they're not bad, but my feeling has always been that they're harder to debug and harder to handle.
On the triggers issue, I'm not sure whether that's necessary for your app. Since the events that trigger the calculations are invoked by the user, those things can happen in PHP, even if the user is redirected to a "waiting" page or another page in the meantime. Obviously, true triggers can only be done on the DB level, but you could use a daemon thread that runs a PHP script every X seconds... Avoid this at all costs and try to get the event to trigger from the user side.
All of this said, I wanted to plug my favorite solution for the data access layer on PHP: Doctrine. It's not perfect, but PHP being what it is, it's good enough. Does most of what you want, and keeps you working with objects instead of database procedures and so forth.
Regarding your title, multiple tiers are, in PHP, totally doable, but you have to do them and respect them. PHP code can call other PHP code, and it is now (5.2+) nicely OO and all that. Do make sure to ignore the fact that a lot of PHP code you'll see around is total crap and does not even use methods, let alone tiers, and decent OO modelling. It's all possible if you want to do it, including doing your own (or using an existing) MVC solution.
将大量功能推送到数据库级别（而不是数据抽象层）的一个问题是，您会被锁定到 DBMS 的功能集。开源软件通常被编写为可以与不同的数据库一起使用（当然并非总是如此）。将来您可能希望能够轻松移植到 postgres 或其他一些 DBMS。现在使用大量 MySQL 特定功能将使这变得更加困难。
One issue with pushing lots of features to the DB level, instead of a data abstraction layer, is that you get locked into the DBMS's feature set. Open source software is often written so that it can be used with different DBs (certainly not always). It's possible that down the road you will want to make it easy to port to postgres or some other DBMS. Using lots of MySQL specific features now will make that harder.
使用数据库服务器提供的触发器和存储过程以及其他功能绝对没有任何问题。它运行良好，并且运行良好，您正在充分利用数据库的潜力，而不是简单地将其降级为简单的数据存储。
然而，我确信，对于这里每一个同意你（和我）观点的开发人员来说，至少有同样多的人持有完全相反的想法，并且在这方面拥有良好的经验。
There is absolutely nothing wrong with using triggers and stored procedures and other features that are provided by your DB server. It works and works well, you are using the full potential of the DB, instead of simply relegating it to being a simplistic data store.
However, I'm sure that for every developer on here who agrees with you (and me), there are at least as many who think the exact opposite and have had good experiences with doing that.
谢谢你们。
我使用数据库触发器是因为我认为这样控制事务完整性可能更容易。正如您可能意识到的那样，我是一名开发人员，也在努力掌握数据库知识。
现在，我看到有一种解决方案可以将 php 代码分布在多个层上，不仅在逻辑上而且在物理上通过部署在不同的服务器上。
然而，在这个开发阶段，我想我会坚持我的触发器/sp 解决方案，因为这感觉并没有那么错误。在多个层上分发需要我一致地重新设计我的应用程序。
另外，考虑开源，如果有人喜欢替代货币系统，人们可能更容易根据自己的要求更改布局，而我不需要担心如果人们接触 php 代码，计算会出错。
另一方面，当然，我同意数据库的东西可能很难调试。
DB 初始化脚本位于源代码管理中，php 文件也是如此:)
再次感谢
Thanks guys.
I was using db triggers because I thought it might be easier to control transaction integrity like that. As you might realize, I am a developer who is also trying to get grip of the db knowledge.
Now, I see there is the solution to spread the php code on multiple tiers, not only logically but also physically by deploying on different servers.
However, at this stage of development, I think I'll stick to my triggers/sp solution, as that doesn't feel to be that wrong. Distributing on multiple layers would require me to redesign my app consistently.
Also, thinking open source, if someone likes the alternative money system, it might be easier for people to just change layout for their requirements, while I would not need to worry that calculations get wrong if people touch php code.
On the other hand, of course, I agree that db stuff might get very hard to debug.
The DB init scripts are in source control, as are the php files :)
Thanks again