2
votes

If making things work is only requirement, we can put all controlling login and DB handling logic even in the views & it will work. However this is not a right approach for reusable design.

Before I ask my real design question, below is my current understanding about separation of responsibilities in terms of model.

  • All Database related code, even db related logic, should go in models.
  • For a table, say 'my_tab', propel generate 4 classes, out of which only 2 classes 'MyTab.php' and 'MyTabPeer.php' should be edited.
  • MyTabPeer.php must only have data fetching.
  • Any logic, if required to fetch data, should go in 'MyTab.php'

This is simple and I hope it is correct, if not, please correct me.

Now, I have a special condition. I've 4 tables, say a, b, c, d. For that, propel generated 8 editable classes (excluding base*.php)

A.php    APeer.php    B.php    BPeer.php
C.php    CPeer.php    D.php    DPeer.php

One page of my application, shows Mailbox (say). Mailbox is not a table in database but it gets its data from complex join query between above 4 tables along with lot of calculation/conditions.

I generated that query, fetch data from it and displayed it. Mailbox is running as expected. However I did it in my controller (action class), which I know is not a right place for that.

My question is, where should I put that code? Possible options:

  • Controller, I think, is not a right place for DB logic/fetch.
  • I've 8 model classed however data do not belong to any one of them but as combination of them all.
  • A separate helper/lib, but I know I'll never reuse that code as its unique page of the site.
  • Anywhere else?

Please suggest if I'm wrong but I guess I should put it in models as it is fetching data. Since A is primary table, I probably should put code in A.php and APeer.php. If that is correct place, next question is, What should go in A.php & what should go in APeer.php? I've following operations to do:

  • Some logic to decide what columns, should I select.
  • As like mailbox, I can show received/sent message. Controller will tell what to show but there are some db logic to set conditions.
  • Then really fetch data from complex Join query.
  • Returned data will have all rows but I might need to merge few rows conditionally.

As per my understanding, Point 3 should go in APeer.php and rest in A.php. Is my understanding correct?

1
If you're building object graphs, you must end with just one object with all its related entities. Which is your object? Mailbox? Can you give more details about the data you're fetching? Is it a list of e-mails?Keyne Viana
@Keyne Thanks for reply. Weekend so even I dont have exact tables but other question stackoverflow.com/questions/12198874/… have the query I'm using. Hope that query will help a bit to understand what I'm doing.Kapil Sharma

1 Answers

1
votes

You should create separate model class i.e. Mailbox. Method of this model should do the complex select and return data to your action in controller. This solution will not break MVC approach.