MVC模式中的业务逻辑在哪里？

Question

我使用Zend框架和Doctrine。在许多项目中，业务逻辑内置于控制器中。这种方法对我来说似乎不对。

我见过的最佳设置是使用服务层，这就是编写业务逻辑的地方。我所要做的就是创建一个表单，验证它，并在服务层中使用一些业务逻辑。结果验证，业务逻辑和使用一种方法（例如：newProduct（$ postData））。

在MVC中组织业务逻辑的正确方法是什么？也许我需要阅读一些书籍，或者看一些源代码示例。

Answer 1

我不能代表Zend框架（或者你正在使用它构建的任何东西），但在MVC模式中，业务逻辑通常属于模型。

您之前可能已经听过这样的陈述，即“应该让控制器保持轻盈，模型变重”（或其中的一些变体）。我们的想法是，模型是您的域（您无处不在的语言），所有业务逻辑都应该在它们和交互中编码。控制器只是MV​​C中的事件处理程序，用于接收请求并将这些请求转换为模型。

编辑：（回应您的评论） - 我担心我们在这里遇到了一些语言障碍。但是，为了增加这一点并希望能够帮助您自己构建模型和数据是主要的，请考虑Eric Raymond的一句话：“智能数据结构和哑代码比其他方式更好。”

我们的想法是“逻辑”在您的数据结构中，您可以构建一个“丰富”的域模型，其中包含逻辑和功能。这与“贫血”域模型相反，后者只是平面数据结构（或DTO），它只是表示数据状态并且没有任何功能。

使用智能数据结构，使用它们的代码（将在您的控制器以及其他各种地方）不需要复杂或复杂。它只需要告诉模型正在发生什么，并指导他们做他们需要做的事情。模特拥有实际操作的所有专业知识。

这比“智能代码和哑数据结构”更受欢迎，其中模型是贫血的DTO（有它们的用途，不要误解我的意思）并且所有逻辑都采用更加程序化的格式，每个程序都需要拥有执行手头业务任务的所有专业知识。除其他外，这会导致许多代码重复。

我希望这会有所帮助。正如我所说，我很难理解你问题的全部内容。

编辑：需要考虑的另一件事，因为我不确定您的“数据是主要”问题。 “数据结构”和“数据持久性”之间存在差异，这种差异在这里绝对至关重要。您的数据结构是您的模型，丰富了业务逻辑。您的数据持久性是数据库中的数据。

很多时候（经常，如果你问我），这些概念在编程中会被混淆。在大多数自动生成的代码和有用的框架以及所有这些内容中，“模型”倾向于直接映射到数据库表并简单地表示这些表中的记录。这并不总是错误的，但这是误导性的。

业务逻辑不在数据库中。它不是数据的平面表示。当然，数据库可以包含自己的持久性逻辑（例如参考完整性，触发器，业务逻辑代码不知道的审计等），但它不包含您通常在流程图中看到的业务流程业务逻辑。

对于任何给定框架的标准操作过程，这些概念可能会脱离模具。正如我所说，我不能真正代表该框架。但就我个人而言，我倾向于提倡“良好的代码”而不是“使用特定工具。”

Answer 2

我将提供一些关于MVC模式编码的观点。对于懒惰的程序员来说，很容易弄乱控制器和模型之间的代码。

下面是我的文件夹结构：

1. 控制器：应该清晰明了，这里唯一要确定应该加载哪些模型或视图来响应请求。
2. 观点：甚至认为它可以直接访问模型，但我更喜欢通过控制器来实现。并保持html清洁。
3. 模特：完成所有事情但分成文件夹。
   • 类/对象：包含基于数据库架构的所有对象。
   • Repository / Factory：包括查询，插入，更新和删除方法。只将一个文件映射到一个表。
   • 服务：业务逻辑，登录，注销或与数据库无关的所有内容，甚至将表连接在一起并返回结果。
   • Utils：基于Repository / Factory的视图的静态方法。

希望这有帮助！并欢迎任何建议。

Answer 3

我会说Business层是Controller的一部分，因为它包含了使用户能够同时与View和Model交互的所有组件。从检索，处理，转换甚至管理应用程序数据和业务规则。