Managing an object comprised of two tables?

BagpussUK posted on Monday, February 16, 2009

Sorry if this is a n00b question, but I am a n00b to CSLA :o)

In the database, we have a candidate table and a person table which have a 1-1 relationship (a person can also be a client contact).  The person table holds name details and the like while the candidate table holds specific info, as well as an intPersonId.

As the user will be editing both sets of information on the same screen, I was wondering if it possible for one csla object to hold information from two tables? Would I use the example of the projectresources class in the ProjectTracker code and create a CandidatePerson class which holds the candidate's child person even though there will only ever be one person...

Sorry if this doesn't make much sense .. as i said, am new to this :o)

Many Thanks 

 

JoeFallon1 replied on Monday, February 16, 2009

You have lots of ways to do this. One is to create a single BO which fetches the data from both tables (using a JOIN query). Then you can have the user edit the screen. When you save the BO you simply have to write 2 Insert/Update statements instead of one. Send some of the data in the BO to one table and send the rest to the other.

Joe

 

Fintanv replied on Monday, February 16, 2009

The question should not be centered around how the data is stored, but rather your use case and how it dictates your customers interaction with the data.   It is entirely possible to have multiple business objects that present different 'views' of the same data.  You can expect some BO's to be 1 to 1 with your tables, others may take data from a myriad of tables and present it in either a flat view and/or a hierarchical view.

As to your specific case, since you mention that your user will be editing both sets of info on the same screen, it makes sense to me that all the data would be in a single BO (KISS principle).

Cheers,
-- Fintan

Jack replied on Tuesday, February 17, 2009

At the very least combine your tables behind the scenes in a stored procedure/view and make a single update/insert from the front-end to another stored procedure.

That will allow you to keep that logic neatly wrapped up in the database and keep the BO cleaner and simpler.

If that model doesn't work based on your data requirements I would suggest then that you likely need to split the BO class apart as well then.

ajj3085 replied on Tuesday, February 17, 2009

Your last suggestion isn't good; having two BOs for this information should only be done if the use case calls for it, or perhaps if there's "sections" of data to enter where the user may nor may not edit a particular section.

But splitting the BO just because it's data comes from two tables wouldn't be use case driven design, it'd be data driven design.

Jack replied on Tuesday, February 17, 2009

ajj3085:

Your last suggestion isn't good; having two BOs for this information should only be done if the use case calls for it, or perhaps if there's "sections" of data to enter where the user may nor may not edit a particular section.

But splitting the BO just because it's data comes from two tables wouldn't be use case driven design, it'd be data driven design.

Just in case that comment was in regards to my comments, I'll just clarify in that I was suggesting that if you updates from the BO makes it such that a single stored procedure can't handle the cases then likely the use case doesn't work. 

As in the example above, if you need to continually call the stored proc twice with half the data each time, then it doesn't work.

I wasn't suggesting that the data & stored procedure should drive the design, simply that if a single stored procedure wasn't working, it would be a very good indicator that the use case was flawed. 

Same idea if you were calling the save twice and doing a if this then save 1/2 of data else save the other 1/2.   I was treating the update SP as an extension of the Save function.

That is quite different than having a complex SProc that does a lot of work updating multiple tables etc. which is a perfectly valid example.

Sorry if I wasn't terribly clear.

jack