如果只需要让事情正常工作，我们甚至可以将所有控制登录和数据库处理逻辑放在视图中，它会起作用。然而，这不是可重用设计的正确方法。
在我提出真正的设计问题之前，以下是我目前对模型方面的职责分离的理解。
- 所有与数据库相关的代码，甚至是与数据库相关的逻辑，都应该放在模型中。
- 对于一个表，比如“my_tab”，推动生成 4 个类，其中只有 2 个类“MyTab.php”和“MyTabPeer.php”应该被编辑。
- MyTabPeer.php 只能获取数据。
- 任何逻辑，如果需要获取数据，都应该进入“MyTab.php”
这很简单，我希望它是正确的，如果不是，请纠正我。
现在，我有一个特殊的条件。我有 4 张桌子，比如 a、b、c、d。为此，propel 生成了 8 个可编辑的类（不包括 base*.php）
A.php APeer.php B.php BPeer.php
C.php CPeer.php D.php DPeer.php
我的应用程序的一页显示邮箱（比如说）。邮箱不是数据库中的表，但它从上述 4 个表之间的复杂连接查询以及大量计算/条件中获取数据。
我生成了该查询，从中获取数据并显示它。邮箱按预期运行。但是我在我的控制器（动作类）中做到了，我知道这不是一个合适的地方。
我的问题是，我应该把代码放在哪里？可能的选项：
- 我认为控制器不是数据库逻辑/获取的正确位置。
- 我有 8 个模型分类，但是数据不属于其中任何一个，而是它们的组合。
- 一个单独的帮助程序/库，但我知道我永远不会重用该代码作为其网站的唯一页面。
- 其他地方？
如果我错了，请提出建议，但我想我应该把它放在模型中，因为它正在获取数据。由于 A 是主表，我可能应该将代码放在 A.php 和 APeer.php 中。如果这是正确的地方，下一个问题是，A.php 中应该包含什么以及 APeer.php 中应该包含什么？我有以下操作要做：
- 一些逻辑来决定我应该选择哪些列。
- 就像邮箱一样，我可以显示收到/发送的消息。控制器会告诉显示什么，但有一些数据库逻辑来设置条件。
- 然后真正从复杂的 Join 查询中获取数据。
- 返回的数据将包含所有行，但我可能需要有条件地合并几行。
根据我的理解，第 3 点应该放在 APeer.php 中，然后放在 A.php 中。我的理解正确吗？