Home/ Questions/Q 6724703
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T09:43:16+00:00

For clarity consider a fairly standard User registration functionality: My ORM (Propel) allows you

  • 0

For clarity consider a fairly standard “User registration” functionality:

My ORM (Propel) allows you to alter the class ormUser, which extends the ormUserBase, in order to introduce custom functionality.

Now that I have coupled Propel with an MVC framework I am wondering which logic should go where from a best practice point of view.

For my user registration functionality I’d create:

  • RegistrationController – which uses the

  • UserModel – which in turn should call something like

  • LoginView
  • LogoutView
  • SignupView
  • ProfileView

The user database table is coupled with user-profile and Propel has generated handy methods to work with these tables. But now Propel’s standard methods are not sufficient and I need to extend functionality.

Where would one do this correctly?

Would I only extend ormUser for new query methods and place non-query logic in my UserModel?
Or would you simply ignore ormUser and use UserModel for everything custom, calling other ormTableNameClass-s there as needed for my logic?

I understand keeping new methods in Propel has the benefit of reusability in other Models and Controllers, but I’m not sure from a “do it correctly” point of view since it seems I need business logic to determine the outcome of certain queries.

UPDATE: Using ORM classes directly from the controller in MVC, bad practice? shows how one usually works with Propel, which in my mind overlaps the framework’s model…

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I come at this from having paired Propel with symfony 1.0 for several years. Perhaps I’ve not understood your post fully, but I am unsure what you think is missing from Propel.

    For clarity, the thing you call a model, I would call “business logic” or an “action”. The model, at least the way I understand the jargon, is the database and the class layer on top of the database. Your “views” are IMO still part of the logic/action section of MVC. I would regard a view as officially referring to something different: the output layer that renders the output of an action.

    In Propel, you basically have three classes for each table: row, peer, and query (historically Propel users have got used to two, since query is new). The row is simple – just a class representation of a database row. The peer is for table-wide operations such as selecting several rows, and the query class is a new chainable API to run statements on the database.

    So, in each of your actions (login, logout, etc) you should call Propel to do the necessary work. Where you find you have a large chunk of code in your action, in most cases it can be refactored into a Propel row or peer. This fits in with the MVC rule of thumb “thin controllers, fat models” i.e. try to keep your db stuff in the controller slim.

    How you should structure your project depends on your framework, but I would show it like this:

        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
    • 0