Page 1 of 1

Multiple-table Models

Posted: Thu Jul 14, 2011 12:01 pm
by thinsoldier
If I have have a giant form that inserts or updates data across 5 tables
should I have my 5 database table classes within my controller?
Or should I make another model that represents the overall item of interest and contains the 5 db table classes?

Should I be using transactions when updating those 5 tables?

Re: Multiple-table Models

Posted: Thu Jul 14, 2011 1:09 pm
by AbraCadaver
I guess you should have 5 models that represent each table and perform validation, relations and business logic. Then the controller should submit the relevant data to the model(s).

Re: Multiple-table Models

Posted: Thu Jul 14, 2011 6:12 pm
by Jonah Bron
AbraCadaver wrote:I guess you should have 5 models that represent each table and perform validation, relations and business logic. Then the controller should submit the relevant data to the model(s).
Not necessarily: a model doesn't ways directly correspond to a table, especially with complex data. But it certainly may in this case.

Could you post the table schemas?

Re: Multiple-table Models

Posted: Thu Jul 14, 2011 8:58 pm
by Christopher
I agree that it sounds like one Model class, given that the form is one business operation. It is possible that it might be more Models than one depending on the design of your database, but probably not one class per table (those would be Datasource Layer objects, not Doman Layer objects).

Yes for transactions.

Re: Multiple-table Models

Posted: Thu Jul 14, 2011 9:52 pm
by AbraCadaver
Well, I made some assumptions based upon some real world examples since the OP didn't elaborate on the type of data or the application. Take a blog post for example: you may have a Posts table, a related Categories table, a related Users table, a related Tags table and maybe more. Is anyone suggesting a single model for a blog post that represents all of these tables and their relationships, validation and business logic? And then separate models for each of the tables so that you can manage categories, users and tags separately?

Re: Multiple-table Models

Posted: Thu Jul 14, 2011 10:01 pm
by Jonah Bron
AbraCadaver wrote:Well, I made some assumptions based upon some real world examples since the OP didn't elaborate on the type of data or the application
I didn't mean to imply that you didn't know that, just clarifying for the OP :)

Re: Multiple-table Models

Posted: Thu Jul 14, 2011 10:04 pm
by AbraCadaver
Jonah Bron wrote:
AbraCadaver wrote:Well, I made some assumptions based upon some real world examples since the OP didn't elaborate on the type of data or the application
I didn't mean to imply that you didn't know that, just clarifying for the OP :)
Sorry, I should have quoted something. I was probably responding more to Christopher's "one Model class". 8)

So just to clarify, maybe Christopher and I are on the same page (not sure). In my simple example, I would have a Posts model that took care of all of the Posts table stuff as well as relating and updating the other tables since we know the relations and they are defined. So for that one operation there is only one model, but it would make use of the other models since they have their independent uses. So we still need models for the individual entities that can be managed independent of the blog posts (tags, categories, etc.). That was my point with the multiple models.

Re: Multiple-table Models

Posted: Fri Jul 15, 2011 8:14 am
by alex.barylski
Or should I make another model that represents the overall item of interest and contains the 5 db table classes?
Interesting question one I still struggle with occasionally. Personally I would implement each as a separate distinct model, with it's own business logic, validations, etc. However I would also implement a facade/strategy to act as a single point of contact for the given controller - if more than one model was required that is.

This is where I think more clarity is required - at least for me. If the model reflects only a single table, and some higher-level abstract model acts as a coordinator between various entity models and the controller:action. I often considered the latter the domain model and individual as entity models. In DDD parlance, I think this may be analogous to an aggregate root?!?

I personally/professionally appreciate the simplicity of implementing models on a per table basis, but when schema are complex enough to require cross-table associations I would prefer to find a way to connect those objects using a more abstract model object. Relying on VIEWS to emulate single table sources and perform complex SELECTS as a separate object - I think this would be analogous to DDD service.

Interesting conversation, keep er' going :)

Cheers,
Alex

Re: Multiple-table Models

Posted: Fri Jul 15, 2011 9:23 pm
by Christopher
AbraCadaver wrote:So just to clarify, maybe Christopher and I are on the same page (not sure). In my simple example, I would have a Posts model that took care of all of the Posts table stuff as well as relating and updating the other tables since we know the relations and they are defined. So for that one operation there is only one model, but it would make use of the other models since they have their independent uses. So we still need models for the individual entities that can be managed independent of the blog posts (tags, categories, etc.). That was my point with the multiple models.
As I said about, there is a distinction between Domain Model objects and Datasource layer objects. However, the term Model applies to a broad range of things in web development.

One goal of a Model object is that it abstracts the underlying Datasource to give you flexibility to change things like the database schema without affecting the application. So a Model object might have a method like $product->findAllSaleItems() which internally might call a Datasource object like $db->select("price < list_price"). Later you could change that call to $db->select("on_sale='yes'") but the Model's $product->findAllSaleItems() method would be unchanged.

So when I hear "one class per table" my thought is that those object tend to be Gateway or ActiveRecord like objects -- and not really Domain objects -- and hence not Models.

Re: Multiple-table Models

Posted: Sat Jul 16, 2011 11:16 pm
by Jonah Bron
Excellent explanation, Christopher.

[via droidx]t