我有一个特定的问题，可以使用一般答案......在PHP中构建多层应用程序时，一切都必须在业务逻辑层中完成，或者任何层都能正常工作......例如，假设我正在构建一个在表示层上显示用户信息（来自数据库）的应用程序。我应该使用业务层简单地将数据传递到表示层，还是直接从表示层中的数据库中获取信息。如果表示层用于呈现数据，那么访问层使用JUST来获取数据，所有工作都在业务层完成？
另外，谈到不同的层，最好是在程序上做事，或者使用OOP（比如使用includes来显示模板，使用类来包含模板，在程序上验证数据与使用类或函数vs）从数据库中获取数据的类等。）
正如您所看到的，我正在努力了解事情是如何运作的，以及最好的做事方式。话虽如此，如果您有任何建议，或任何有关该主题的一般提示......请留下他们..
由于
答案 0 :(得分：3)
Web应用程序和N层很有意思，主要是因为随着JSON和AJAX，或Flash和XMLRPC的广泛采用，N层的概念已经扩展。此chart on Webopedia显示交错的蓝线，表达了这一点。总结一下：您的业务，访问者和表示逻辑不仅可以存在于服务器上 - 而且在某些情况下，可以存在于浏览器中。然而，N层的意图是可分离性。如果您需要更改UI或数据库，或添加其他UI，则不应影响业务逻辑。这就是决定你的API的原因 - 预计你的HTML和CSS被弃用的那一天，并且为Oracle改变了MySQL。
这是需求确定的，在我使用过的一些Web应用程序中，同时使用了N层的变体。以LyrisHQ（电子邮件ASP）为例。他们有一个客户Web应用程序。最近，他们盯着推动基于Flash的应用程序。这显然会将大量数据传递给浏览器，并且Flash UI中可能存在一些重复的业务逻辑。但是，他们必须维护这两个应用程序，因为任何一个都是不同（和重叠）要求所必需的。
大多数常见的PHP应用程序都没有考虑将大量未格式化的数据传输到浏览器。但如果你这样做，这将很快告诉你如何设计你的API。很可能，除了PHP演示模板使用的类似内部控制器类之外，您还需要能够与XMLRPC，REST或SOAP ...进行对话的控制器。这将严格意味着一个简单的Web登录页面，您将拥有一个与LoginController类对话的登录表单的PHP模板。 XML接口同样使用相同的LoginController类。就像你会假设你将SQL写入Ajax请求一样疯狂......你将严格避免在你的演示模板中编写查询。
业务层可以或多或少地严格，因为通常不需要切换数据库后端的品牌。在严格的N层设计中，业务对象如何与数据库通信就好像您可以从MySQL切换到MS SQL而无需重写业务层。有时，这是通过为每个表（表网关），每行（活动记录），每个联接或每个事务建模对象来完成的。这是像PDO或PHP-ADO这样的东西很有用，但不足以完全隔离。像Hibernate这样的Java中的ORM / Persistence层通常通过提供对象查询语言（OQL）来更好地证明这种隔离。
我自己，我目前正在进行从基于MySQL的PHP应用程序到MS-SQL应用程序的后端转换。该应用程序只使用过直接SQL查询。想象一下，选择如何在类中进行一系列查询，并抽象它们或子类化，并希望不改变业务逻辑。至少，您需要间接地进行所有SQL调用。 （S.O. post on PHP ORM。）
最后，关于OOP的问题：使用它如何满足您的要求。我的个人技术是在PHP演示模板中开始使用逻辑几分钟来推动滚动，很快我就会将它重构成一个类和一个模板。如果我有共同的想法，我会将例程分解为共享类，努力保持DNRY原则。 （S.O. post on that here. OOP不是N层设计的基本要求.DNRY对于保持代码的可维护性非常重要。通常截止日期和范围转移会破坏API。重构它直到得到你需要的东西继续。我打赌OOP会帮助你到那儿。
答案 1 :(得分：2)
我曾经读过一些话说大型模特（商业层）应该比大型控制器（访问层）更受欢迎。
另外：这实际上取决于项目。在我看来，将OOP用于所有事情并不总是有意义的（可能不是每个人都会在这里同意），特别是在像PHP这样的脚本语言中，通常更容易将验证器作为函数...
答案 2 :(得分：1)
我绝对建议你不要在表示层中进行数据库调用，否则会破坏它的目的。
multi-tier architecture有不同的方法，他们有不同的建议。
我使用过的Zend Framework通常采用Fat model / Thin controller variant的形式。
如果发现本文Notes on Choosing a PHP Framework非常擅长比较（在本例中）CakePHP和Zend Framework。
我的opionion最大的不同之处在于CakePHP采用的约定优于配置的方法，这与Zend Framework中的配置焦点非常不同。
通过使用一个框架，如果实现多层体系结构很有意义，那么你的强制或者至少会被迫使用OOP，这不是一件坏事。
你当然可以实现，比如一个带有纯函数调用的3层架构，但根据我的经验，它不能很好地扩展。
对于一个网站来说，MVC模式实际上因为层级沟通的方式而大不相同，是一个不错的选择。
“普通”3层拱和MVC模式之间的区别在于视图可以访问控制器和模型层，因为表示层只能访问3层的逻辑层拱。
答案 3 :(得分：0)
我同意Franz所说的，特别是关于更大型号而不是大型控制器...您还可以使用经验法则来区分代码应该去哪里：如果它与UI结构/流程有任何关系，那就放它在控制器中;如果它是纯粹的商业逻辑，它就在模型中......
我要补充一点，作为一名Java开发人员，在测试PHP水域之前有很多Struts经验，我花了一些时间来了解如何将MVC思想应用到脚本语言中。我个人发现使用像CodeIgnitor这样的系统帮了很多...它提供了框架，就像Struts一样，并且鼓励好的MVC模式。
答案 4 :(得分：0)
我的世界看起来像这样：
DB1＆lt; - Model1提供访问者 功能，数据完整性，业务 此数据集的规则DB2＆lt; - Model2 提供访问者功能，数据 诚信，业务规则 数据集
控制器：控制数据流向 视图，过滤/组织数据 观点。实现业务规则 给定的应用程序。知道了 业务规则介于模型之间。
观点：只不过是模板 显示由...提供的数据 控制器。将所有数据传递给 控制器。不知道 Model1或Model2或业务 管理他们的逻辑。
答案 5 :(得分：0)
我建议对设计模式进行一些研究，因为这是你拼图中缺失的一部分。有很多特定于PHP的书籍涵盖了这个主题（来自APress的书籍很好）以及设计模式的“圣经”："Design Patterns: Elements of Reusable Object-Oriented Software"
答案 6 :(得分：0)
让我们等待Doctrine2更稳定的版本。
它是用持久性无知的领域对象哲学开发的。借助该框架开发多层应用程序将更加容易。