PHP 中的多层......正确的方法吗？
我有一个具体的问题，可以使用一般答案...在 PHP 中构建多层应用程序时，是否所有内容都必须在业务逻辑层中完成，或者任何层都可以工作...示例，可以说我正在构建一个在表示层上显示用户信息（来自数据库）的应用程序。我应该使用业务层将数据简单地传递到表示层，还是直接在表示层内从数据库获取信息。表示层是否应该仅用于呈现数据，访问层仅用于获取数据，而所有工作都在业务层中完成？
另外，谈到不同的层，最好是按程序执行操作，还是使用 OOP（例如使用包含来显示模板与使用类来包含模板，按程序验证数据与使用类，或者函数与类来获取来自数据库的数据等。）
如您所见，我试图了解事物是如何工作的，以及做事的最佳方式。话虽这么说，如果您对这个主题有任何建议或任何一般提示......请留下它们......
谢谢
I have a specific question, that could use a general answer... When building Multi-Tier applications in PHP, does everything have to be done in the Business Logic layer, or can any layer do work... Example, Lets say I'm building an application that shows user information (from the database) on the presentation layer. Should I use the business layer to simply pass the data to the presentation layer, or just get the information from the database directly within the presentation layer. Should the presentation layer be used JUST for presenting the data, the accessor layer used JUST to get the data, and all the work be done in the business layer?
Also, speaking of the different layers, is it best to do things procedurally, or using OOP ( like using includes to show the templates vs using a class to include the templates, validating data procedurally vs using a class, or functions vs classes for getting the data from the database, etc. )
As you can see, I'm trying to understand how things work, and the best way to do things. That being said, if you have any advice, or any general tips on the subject... please leave them..
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Web 应用程序和 N 层很有趣，主要是因为 N 层的概念随着 JSON 和 AJAX 或 Flash 和 XMLRPC 的广泛采用而扩展。 Webopedia 上的图表显示了一条交错的蓝线，很好地表达了这一点。总结一下：您的业务、访问器和表示逻辑不仅可以存在于服务器上，而且在某些情况下也可以存在于浏览器中。然而，N 层的目的是可分离性。如果您需要更改 UI 或数据库，或添加其他 UI，则不应影响您的业务逻辑。这就是决定你的 API 的因素——预计有一天你的 HTML 和 CSS 会被 Flex 抛弃，MySQL 会被 Oracle 取代。
这是确定的要求，并且在我使用的一些 Web 应用程序中，同时使用 N 层的变体。以 LyrisHQ（电子邮件 ASP）为例。他们有一个客户网络应用程序。最近，他们开始推出基于 Flash 的应用程序。这显然将大量数据直接传送到浏览器，并且 Flash UI 中可能存在一些重复的业务逻辑。然而，他们必须维护这两个应用程序，因为其中一个应用程序对于不同（且重叠）的需求是必需的。
大多数常见的 PHP 应用程序都不会考虑向浏览器传送大量未格式化的数据。但如果您是的话，这会很快告诉您想要如何设计 API。很可能，除了 PHP 演示模板使用的类似内部控制器类之外，您还需要能够使用 XMLRPC、REST 或 SOAP 的控制器。这严格意味着对于一个简单的 Web 登录页面，您将有一个用于与 LoginController 类对话的登录表单的 PHP 模板。 XML 接口同样会使用相同的 LoginController 类。正如您认为您会疯狂地将 SQL 写入 Ajax 请求一样...您将严格避免将查询写入演示模板。
业务层可以或多或少严格，因为通常不需要切换数据库后端的品牌。在严格的 N 层设计中，业务对象与数据库的通信方式就好像您可以从 MySQL 切换到 MS SQL，而无需重写业务层。有时，这是通过为每个表（表网关）、每行（活动记录）、每个连接或每个事务建模对象来完成的。这就是 PDO 或 PHP-ADO 等有用的地方，但不足以完全隔离。 Java 中的 ORM/持久层（例如 Hibernate）通常通过提供对象查询语言 (OQL) 来更好地展示这种隔离。
我本人目前正在进行从基于 MySQL 的 PHP 应用程序到 MS-SQL 应用程序的后端转换。该应用程序仅使用过直接 SQL 查询。想象一下，选择如何在一个类中进行一系列查询，然后对它们进行抽象或子类化，并希望不会改变业务逻辑。至少，您希望所有 SQL 调用都是间接的。 （关于 PHP ORM 的帖子。）
最后，关于 OOP 的问题：如何使用它你必须满足你的要求。我个人的技术是从 PHP 演示模板中的逻辑开始，花几分钟来开始工作，很快我就会将其重构为一个类和一个模板。如果我有共同的想法，我会将例程分解为共享类，努力维护 DNRY 原则。 （SO 帖子在这里。 OOP 不是基本要求对于 N 层设计来说，DNRY 对于保持代码的可维护性非常重要，但截止日期和范围转移通常会破坏 API，直到您获得继续运行所需的内容。
Web applications and N-tier is interesting, mostly because the notion of N-tier has expanded with the widespread adoption of JSON and AJAX, or Flash and XMLRPC. This chart on Webopedia displays a staggered blue line that expresses this well. To summarize: your business, accessor, and presentation logic not only could exist on the server--but in some cases, right in the browser. The intention of N-tier, however, is separability. If you need to change out your UI or your database, or add other UIs, you shouldn't be affecting your business logic. And this is what would determine your API--anticipating the day your HTML and CSS are discarded for Flex, and MySQL is changed out for Oracle.
This is requirements determined, and in some web applications I've used, variations of N-tier are used simultaneously. Take for example LyrisHQ (an e-mail ASP). They have a customer web application. Recently, they have stared pushing their Flash based application. This clearly is shipping a lot of data right to the browser, and there is probably a bit of business logic duplicated in the Flash UI. They must maintain both applications, however, since either one is necessary for different (and overlapping) requirements.
Most common PHP applications are not considering shipping much unformatted data to the browser. But if you were, this would inform you very quickly how you would want to design your APIs. Very likely, you would want controllers that could talk XMLRPC, REST, or SOAP...in addition to a similar internal controller class that your PHP presentation templates used. This would strictly mean for a simple web login page, you would have a PHP template for the login form that talked to a LoginController class. An XML interface would likewise use the same LoginController class. Just as you would assume that you would be bonkers to write SQL into an Ajax request...you would be strictly avoiding writing queries into your presentation templates.
Business layers can be more or less strict, because often there is never a requirement to switch brands of database back-end. In a strict N-tier design, how your business objects would talk to your database would be as if you could switch from MySQL to MS SQL without rewriting the Business tier. Sometimes this is done by modeling objects for each table (Table Gateway), each row (active record), each join, or each transaction. This is where something like PDO or PHP-ADO are useful, but insufficient for complete isolation. ORM/Persistence layers in Java like Hibernate demonstrate better this kind of isolation, often by providing an Object Query Language (OQL).
Myself, I am presently undertaking a back-end transition from a MySQL based PHP application over to an MS-SQL one. The application has only ever used direct SQL queries. Imagine choosing how to take a series of queries in a class and either abstracting them, or subclassing, and hopefully not altering the business logic. At the very minimum, you will want to make all your SQL calls indirect. (S.O. post on PHP ORM.)
And finally, to your question about OOP: use it how you must to fulfill your requirements. My personal technique is to start with logic right in a PHP presentation template for a few minutes to get the ball rolling, pretty soon I'll refactor that into a class and a template. If I have common ideas, I break out routines into shared classes, striving to preserve the DNRY principle. (A S.O. post on that here. OOP is not a fundamental requirement for N-tier design. DNRY is very important for keeping your code maintainable, tho. Often deadlines and scope-shift destroy an API. Refactor it until you get what you need to keep going. I bet OOP will help get you there.
我曾经读过一些内容，说大模型（业务层）应该优先于大控制器（访问层）。
另外：这确实取决于项目。在我看来，将 OOP 用于所有事情并不总是有意义（可能不是每个人都会同意），特别是在像 PHP 这样的脚本语言中，通常更容易将验证器简单地用作函数......
I once read something saying that big models (business layer) should be preferred over big controllers (accessor layer).
Also: It really depends on the project. In my eyes it doesn't always make sense to use OOP for everything (probably not everyone will agree here), especially in scripting languages like PHP it oftentimes is easier to simply do validators as functions...
我绝对建议您不要在表示层中进行数据库调用，否则会违背其目的。
多层架构有不同的方法，并且它们有不同的建议。
我使用过的 Zend Framework 通常采用胖模型/瘦控制器变体的形式。
如果发现这篇文章选择 PHP 框架的注意事项 非常擅长比较（在本例中）CakePHP到 Zend 框架。
我认为最大的区别是 CakePHP 采取的约定优于配置的方法，这与 Zend Framework 中的配置重点非常不同。
通过使用框架（这对于实现多层架构来说非常有意义），您在某种程度上被迫或至少被迫使用 OOP，这并不是一件坏事。
您当然可以实现，例如具有纯函数调用的 3 层架构，但根据我的经验，它的扩展性不会那么好。
对于网站来说，MVC 模式实际上是一个不错的选择，因为各层之间的通信方式不同，所以 MVC 模式实际上有很大不同。
“普通”3 层架构和 MVC 模式之间的区别在于，视图可以访问控制器和模型层，而表示层只能访问 3 层架构的逻辑层。
I definitely advise you not to have database calls in the presentation layer, that would defeat its purpose.
There are different approaches to multi-tier architecture and they have different recommendations.
Zend Framework that i've worked with is usually of the form Fat model/Thin controller variant.
If find this article Notes on Choosing a PHP Framework to be pretty good at comparing (in this case) CakePHP to Zend Framework.
The biggest difference in my opionion is the convention-over-configuration approach taken by CakePHP which is very different from configuration focus in Zend Framework.
By using a framework, which makes a lot of sense if implementing a multi-tier architecture, your are in a way forced or at least pushed into using OOP, which is not a bad thing.
You could of course implement, say a 3-tier architecture with pure functional calls, but it would not scale that well based on my experience.
For a website the MVC pattern which actually is quite different because of the way the tiers communicate, is a good choice.
The difference between a "normal" 3-tier arch and the MVC pattern is that the view has access to both the controller and the model layer, where as the presentation layer only has access to the logic layer of the 3-tier arch.
我同意 Franz 所说的，特别是关于更喜欢更大的模型而不是更大的控制器。您还可以使用经验法则来帮助区分代码应该放在哪里：如果它与 UI 结构/流程有任何关系，请将其放在控制器;如果它是纯粹的业务逻辑，那么它就在模型中。
我要补充一点，作为一名 Java 开发人员，在测试 PHP 水域之前，他在 Struts 方面拥有丰富的经验，我花了一段时间才了解如何将 MVC 思想应用到一种脚本语言..我个人发现使用像 CodeIgnitor 这样的系统有很大帮助..它提供了框架，很多像 Struts 一样，并鼓励良好的 MVC 模式..
i agree with what Franz said, especially about preferring larger models over larger controllers.. you can also use a rule of thumb to help distinguish where code should go: if it has anything to do with the UI structure/flow, put it in the controller; if it's pure business logic, it goes in the model..
i'll add that as a Java developer that had a lot of experience with Struts before testing out the PHP waters, it took me a while to understand how to apply MVC ideas to a scripting language.. i personally found that using a system like CodeIgnitor helped a lot.. it provides the framework, much like Struts, and encourages good MVC patterns..
我的世界是这样的：
My world looks like this:
我建议对设计模式进行一些研究，因为这是您拼图中缺失的一块。有许多特定于 PHP 的书籍涵盖了该主题（APress 中的书籍很好）以及设计模式的“圣经”："设计模式：可重用面向对象软件的元素"
I recommend doing some research on Design Patterns as this is the missing piece of your puzzle. There are a number of PHP-specific books that cover this topic (the ones from APress are good) as well as the 'bible' of Design Patterns: "Design Patterns: Elements of Reusable Object-Oriented Software"
让我们等待更稳定的 Doctrine2 版本。
它是按照持久性无知的领域对象哲学来开发的。借助该框架，开发多层应用程序将变得更加容易。
Let's wait for more stable version of Doctrine2.
It's being developed with persistence-ignorant domain object philosophy. It will be much easier to develop multi-tier application with help of this framework.