MVC和ORM - 哪个模型逻辑去哪里？

为清楚起见考虑一个相当标准的“用户注册”功能：MVC和ORM - 哪个模型逻辑去哪里？

我的ORM（波轮）允许您更改类ormUser，它扩展了ormUserBase，以引入自定义功能。

现在我已经将Propel与MVC框架耦合在一起了，我想知道从最佳实践的角度出发，应该采用哪种逻辑。

对于我的用户注册功能我想创建：

这个RegistrationController - 它使用

的usermodel - 这反过来应该调用类似

LoginView

LogoutView

SignupView

ProfileView

的用户数据库表加上用户概况，推动已产生的便利方法与这些表来工作。但是现在Propel的标准方法还不够，我需要扩展功能。

哪里可以正确地做到这一点？

请问我只延长ormUser新查询的方法，并把非查询逻辑在我的usermodel？或者你会简单地忽略ormUser和使用的usermodel的一切习惯，根据需要为我的逻辑调用其它ormTableNameClass -s呢？

我知道在Propel中保留新方法在其他模型和控制器中具有可重用性的好处，但我不确定从“做得正确”的角度来看，因为它似乎需要业务逻辑来确定结果某些查询。

UPDATE：Using ORM classes directly from the controller in MVC, bad practice?展示了如何一个通常与行走，它在我的脑海里重叠架构的模型......

来源

2011-10-14 MattW

这取决于你想添加的功能类型。你能给个例子吗？ –

当然 - 说我想创建一个公开的“显示用户配置文件的字母”视图。我需要分页逻辑和多个查询，其中大部分都是Propel原生的，但是让我们假设它们没有被完全覆盖。假设我在查询本身中需要与数据库不相关的逻辑。我将在Propel中创建一个方法，该方法接受分页的参数，从我的模型执行此方法并正在工作，还是我会在我的模型中完成所有工作？ – MattW

在这种情况下，控制器应检索按字母顺序排列的用户模型列表，并将该列表传递给视图。该视图然后构建用户配置文件的实际列表的HTML输出。我不知道Propel是如何工作的，但不应该将检索逻辑添加到用户模型中。理想情况下，您将创建一些与Propel交互的用户存储库类，并且该类将负责从数据库中检索用户对象。 –

我来到这个工作从具有配对行走用symfony 1.0好几年了。也许我还没有完全理解你的帖子，但我不确定你认为从Propel中错过了什么。

为了清楚起见，您称之为模型的东西，我称之为“业务逻辑”或“动作”。该模型至少是我理解行话的方式，是数据库顶部的数据库和类层。你的“观点”是IMO仍然是MVC逻辑/动作部分的一部分。我认为一个视图正式引用了不同的东西：呈现动作输出的输出层。在Propel中，每个表基本上有三个类：行，对等和查询（历史上Propel用户习惯了两个，因为查询是新的）。该行很简单 - 只是数据库行的类表示。对等体用于全表操作，如选择多行，查询类是一个新的可链接的API，用于在数据库上运行语句。

因此，在您的每个操作（登录，注销等）中，您应该打电话给Propel来完成必要的工作。如果你发现自己的行为中有大量的代码，在大多数情况下，它可以被重构为Propel行或peer。这符合MVC的经验法则“薄控制器，胖模型”，即试图保持你的数据库的东西在控制器苗条。

你应该如何构造的项目依赖于你自己的框架，但我会证明它是这样的：

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

来源

2011-10-16 19:11:28 halfer

请您详细说明UserAction/OtherActions如何与海誓山盟和Propel课程相关？我不确定我是否理解，但我相当肯定他们不是Propel生成的类，而是构建Propel对象并使用它们，将结果返回给Controller？ – MattW

正确，Action和View元素是您的框架的一部分，而不是ORM的一部分。一些用例可以由框架生成 - 我相信这些被称为“脚手架”（Rails）或“管理生成器”（symfony）。它们通常仅用于特定表格上的列表细节视图（例如“订单”）。对于这里所有的用例，我认为你会手动编写这些文件。（附录：如果你运行MVC教程，三部曲的各个部分之间的轮廓将变得更加清晰，Jobeet非常好，但只适用于较老版本的symfony。） – halfer

因此，UserAction充当中间层控制器与其可以调用的实际操作之间;它代表了注册领域内所有与用户相关的操作的入口。 SomeAction具有所有业务逻辑并使用Propel。在这种情况下，Propel处理实际的模型，数据库。很酷，我现在明白了我的想法:) - 谢谢。 – MattW

MVC和ORM - 哪个模型逻辑去哪里？

回答

相关问题