我对MVC的理解如下(以防万一，这是非常错误的，毕竟我是新手)

• 模型是与数据库交互的东西
• 视图是页面的设计/布局
• 控制器是一切开始的地方，本质上是页面逻辑

我正在使用CodeIgniter，但我可能会猜测，不仅限于此，甚至可能仅限于PHP框架。

我应该把全局课程放在哪里？

我可能有一个用于"产品"的模型，然后运行一个查询，该查询从数据库中收集了20种产品。我现在要制作20个模型，还是应该为它建立一个单独的类，如果是后者，我应该在哪里放置这个类(其他控制器也需要使用它)

解决方案

在CakePHP中，还有3个"部分"：

• 行为举止
• 成分
• 帮手

许多模型使用的逻辑应作为一种行为。我不知道CodeIgniter是否具有此逻辑，但是如果没有，我将尝试以这种方式实现。我们可以在此处了解有关行为的信息。

(组件可以帮助控制器共享逻辑，而助手可以以相同的方式帮助视图)。

在讨论如何处理产品时，模型是错误的用词：每个产品都是价值对象(VO)(或者数据传输对象/ DTO，更适合口型)。值对象通常具有表包含的相同字段。在情况下，ProductVO应该具有"产品"表中的字段。

模型是数据访问对象(DAO)，其方法如下

findByPk --> returns a single value object
findAll --> returns a collection of value objects (0-n)
etc.

在情况下，我们将拥有一个具有类似于上述方法的ProductDAO。然后，此ProductDAO将返回ProductVO和它们的集合。

数据访问对象还可以返回业务对象(BO)，其中可能包含多个VO和特定于业务案例的其他方法。

附录：
在控制器中，我们可以调用ProductDAO来查找所需的产品。
然后将返回的ProductVO传递到视图(作为Java中的请求属性)。然后，视图循环浏览/显示来自productVO的数据。

模型是业务逻辑发生的应用程序的一部分。模型表示现实生活中的关系和对象之间的依赖关系，例如：员工向经理报告，经理监督许多员工，经理可以将任务分配给员工，逾期时任务会发出通知。对CAN进行建模，最常见的是将DO与数据库建立接口，但这不是必需的。

视图基本上是可以显示或者帮助显示的所有内容。 View包含模板，模板对象，处理模板组成和嵌套，使用页眉和页脚进行换行，并以一种众所周知的格式(X / HTML，以及XML，RSS / Atom，CSV)生成输出。

控制器是一个转换层，可将用户操作转换为模型操作。换句话说，它告诉模型该怎么做并返回响应。控制器方法应尽可能小，所有业务处理应在模型中完成，视图逻辑处理应在视图中进行。

现在，回到问题。这实际上取决于每个产品是否需要单独的类。在大多数情况下，一个类就足够了，应该创建它的20个实例。产品代表业务逻辑，因此应属于应用程序的模型部分。

最简单的方法是：

• 每个数据库表都有一个模型类。在这种情况下，它将是一个包含所有产品详细信息的对象。
• 将这些类放入包/命名空间中，例如com.company.model(Java / C＃)
• 将DAO类放入com.company.model.dao之类的包中
• 视图将使用会话/请求/控制器中的数据。在这种情况下，我将拥有一个List <Product>。
• 哦，我们正在使用PHP。 Dunno会如何改变事物，但我想它具有像任何现代语言一样的Collections框架。

@Alexander提到CakePHP的行为，组件和助手。这些对于抽象出通用功能非常有用。我发现"行为"特别有用，因为大多数业务逻辑当然都包含在模型中。我目前正在从事一个行为类似的项目：

• 可上锁
• 可发布的
• 可标记的
• 须评等
• 值得评论

等等。

对于甚至超越MVC框架的代码，即我们用于各种事物的代码库，这些代码库都未绑定到特定的框架(在我们的案例中，例如视频编码类等)。CakePHP具有vendors文件夹。

实际上与CakePHP无关的所有内容都在其中。

我怀疑CodeIgniter的结构不够灵活，它比CakePHP更小，更轻，但是快速浏览一下CakePHP手册，了解"行为"，"组件"，"帮助器"和" Vendors"文件夹可能会有所帮助。

仅包含模型中的一些常见帮助器类应该很容易，保持良好且干燥