代码之家  ›  专栏  ›  技术社区  ›  unsafe_where_true

使用PHP的多层应用程序?

  •  2
  • unsafe_where_true  · 技术社区  · 16 年前

    我对PHP相对较新,但在具有SOA架构和多层应用程序的复杂企业环境中经验丰富的Java程序员。在那里,我们通常在中间层实现具有业务逻辑的业务应用程序。

    我正在编写一个替代货币系统,该系统应该易于部署,并可由个人和社区定制;它将是开源的。这就是为什么php/mysql似乎是我的最佳选择。

    用户拥有账户,并获得余额。此外,该系统根据提供的总服务和总可用资产计算价格。

    人们怎么想?这是一个好方法吗?我的经验告诉我,这不是最好的解决方案,并促使我实施中间层。然而,我甚至不知道该怎么做。另一方面,在我看来,到目前为止,我在商店采购方面所拥有的似乎是最合适的。

    我希望我把问题说清楚了。所有评论均受到赞赏。可能没有“完美”的解决方案。

    4 回复  |  直到 16 年前
        1
  •  1
  •   Dan Rosenstark    16 年前

    正如当今的趋势一样,离开DB通常是一件好事。您可以更轻松地进行版本控制,并且只需使用一种语言即可工作。更重要的是,我觉得存储过程是一条艰难的道路。另一方面,如果你喜欢这些东西,并且对MySql中的SP感到满意,它们还不错,但我的感觉一直是它们更难调试和处理。

    关于触发器问题,我不确定这对你的应用程序是否有必要。由于触发计算的事件是由用户调用的,因此即使用户在此期间被重定向到“等待”页面或另一个页面,这些事情也可能在PHP中发生。显然,真正的触发器只能在数据库级别完成,但您可以使用每X秒运行一个PHP脚本的守护进程线程。..不惜一切代价避免这种情况,并尝试从用户端触发事件。

    综上所述,我想在PHP上插入我最喜欢的数据访问层解决方案: Doctrine 它并不完美,但PHP本身就足够好了。做你想要的大部分事情,并让你使用对象而不是数据库过程等等。

    关于你的标题,在PHP中,多层是完全可行的,但你必须做到并尊重它们。PHP代码可以调用其他PHP代码,现在(5.2+)很好地实现了面向对象。一定要忽略这样一个事实,即你周围看到的很多PHP代码都是垃圾,甚至没有使用方法,更不用说层次和体面的OO建模了。如果你想这样做,这一切都是可能的,包括做你自己的(或使用现有的)MVC解决方案。

        2
  •  1
  •   acrosman    16 年前

    将大量功能推送到数据库级别而不是数据抽象层的一个问题是,您会被锁定在DBMS的功能集中。开源软件通常被编写为可以与不同的DB一起使用(当然并不总是如此)。未来,您可能希望更容易移植到postgres或其他DBMS。现在使用许多MySQL特定的功能将使这变得更加困难。

        3
  •  0
  •   Anti Veeranna    16 年前

    使用触发器、存储过程和DB服务器提供的其他功能绝对没有错。它工作得很好,你正在充分利用数据库的潜力,而不是简单地将其降级为一个简单的数据存储。

    然而,我相信,对于这里每一个同意你(和我)观点的开发人员来说,至少有同样多的人持相反的观点,并且有过这样做的良好经验。

        4
  •  0
  •   unsafe_where_true    16 年前

    谢谢你们。

    我使用db触发器是因为我认为这样控制事务完整性可能更容易。正如您可能意识到的,我是一名开发人员,也在努力掌握数据库知识。

    现在,我看到有一种解决方案可以将php代码分布在多个层上,不仅在逻辑上,而且在物理上,通过部署在不同的服务器上。

    然而,在开发的这个阶段,我认为我会坚持我的触发器/sp解决方案,因为这感觉没有那么错。在多层上分发需要我始终如一地重新设计我的应用程序。

    此外,考虑到开源,如果有人喜欢替代货币系统,人们可能更容易根据自己的需求更改布局,而我不必担心如果人们接触php代码,计算会出错。

    当然,另一方面,我同意db的东西可能很难调试。

    再次感谢

    推荐文章