为清楚起见，请考虑相当标准的“用户注册”功能：
我的ORM（Propel）允许您更改扩展 ormUserBase 的类 ormUser ，以便引入自定义功能。
既然我已将Propel与MVC框架相结合，我想知道哪种逻辑应该从最佳实践的角度出发。
对于我的用户注册功能，我创建：
RegistrationController - 使用
UserModel - 反过来应该调用类似
- LoginView
- LogoutView
- SignupView
- ProfileView
用户数据库表与用户配置文件相结合，Propel已经生成了方便的方法来处理这些表。但是现在Propel的标准方法还不够，我需要扩展功能。
一个人会在哪里正确地做到这一点？
我是否只会为新的查询方法扩展 ormUser 并在我的 UserModel 中放置非查询逻辑？ 或者您是否只是忽略 ormUser 并使用 UserModel 进行自定义，根据我的逻辑需要调用其他 ormTableNameClass -s？
我理解保持Propel中的新方法在其他模型和控制器中具有可重用性的好处，但我不确定从“做得对”的观点，因为我似乎需要业务逻辑来确定某些结果查询。
更新： Using ORM classes directly from the controller in MVC, bad practice?显示了人们通常如何使用Propel，在我看来它与框架的模型重叠......
答案 0 :(得分：0)
我是通过将Propel与symfony 1.0配对几年来实现的。也许我没有完全理解你的帖子，但我不确定你认为Propel缺少什么。
为了清楚起见，你称之为模型的东西，我称之为“业务逻辑”或“行动”。该模型，至少我理解行话的方式，是数据库和数据库顶部的类层。你的“观点”是IMO仍然是MVC逻辑/行动部分的一部分。我认为一个视图正式指代不同的东西：呈现动作输出的输出层。
在Propel中，每个表基本上有三个类：行，对等和查询（历史上，Propel用户已经习惯了两个，因为查询是新的）。该行很简单 - 只是数据库行的类表示。对等体用于表范围的操作，例如选择多行，查询类是用于在数据库上运行语句的新的可链接API。
因此，在您的每个操作（登录，注销等）中，您应该致电Propel进行必要的工作。如果您发现在操作中有大量代码，在大多数情况下，它可以重构为Propel行或同行。这符合MVC经验法则“瘦控制器，胖模型”，即尽量保持控制器中的db内容。
你应该如何构建你的项目取决于你的框架，但我会这样显示：
RegistrationController - which uses the
UserAction - which in turn should call something like
LoginAction (rendered by LoginView)
LogoutAction (rendered by LogoutView)
SignupAction (rendered by SignupView)
ProfileAction (rendered by ProfileView)
- each of which access the model UserModel