Dealing with differences between Object Model and Data Model

Dealing with differences between Object Model and Data Model

Old forum URL: forums.lhotka.net/forums/t/12864.aspx


jasonabi posted on Friday, April 17, 2015

Generally our CSLA business objects correspond 1-to-1 with our database tables. 


MamaWidget is persisted to mamawidget_table

and

BabyWidget is persisted to babywidget_table

Problem is MamaWidget is so fat....I said MamaWidget is SO FAT...How fat is she?

MamaWidget is SO FAT her property list looks like the list of ingredients in a twinkie.


Alright, excuse the poor attempt at humor.  Point is the parent object has gotten too bloated and I would like to decompose some of it into a few child objects, but this should not effect the persistance, which saves all editable property values to a single table.

This deviates from the way we tend to wire up our CSLA objects, but seems like the right thing to do.  I don't want to change the database schema, just the object hierarchy. 

Is there an example of persisting a business object with children into a flattened schema?

Thanks.

 

ajj3085 replied on Friday, April 17, 2015

Your Csla objects should model the use case the user is working from.  Your database should be the normalized storage for the data entered.  While for simple cases they may match up closely, its actually quite normal for your Csla objects to have a different shape than the db tables, which means they might be denormalized, only contain a subset of data from a table, etc.

So I'd say by decomposing things you're actually fixing a design issue you currently have.  Just decompose them according to the use case for the user, which typically will be closely related to what's on the users screen.

jasonabi replied on Friday, April 17, 2015

Yes, the decomposition is to address the "god object" code smell and break the big object into a few smaller more narrowly focused objects - but in terms of persistence, the newly created child objects really just represent clusters of tightly related properties of the parent object.  The decomposition will increase the readability and maintainability of the type(s).  Yet, all of the props on parent and child are really describing a single denormalized entity in the db schema. 

For example, let's say I have a type called "body" and it contains properties that describe all the limbs and organs, etc. I want to decompose it into a parent object "Body" with many children such as "Hand", "Heart", "Brain", etc. each with their own attributes, but it will all still be persisted in the body table in a completely flat schema.

So, what is the difference in terms of DataPortal method implementation?  If I want to save a parent and child simultaneously in the same operation, what do I do?

I'm used to saving child objects along with a parent, but in their own Csla DataPortal_Create (or whatever) method. If I want both to be persisted in the parent object save, how is that wired up? Am I making sense?

Thanks.

 

 

ajj3085 replied on Monday, April 20, 2015

I'd probably just have the save logic in the children, and only the save logic which the parent owns should be in the parent.  So the properties that Body has will be saved in its DP_I/U and the rest will be handled by the children.  That means you'll probably have multiple updates to the same table, unless you're using something like EF, where you'd probably want to pull the data object from your context in each object and manipulate just the fields which are "owned" by the object, letting only your root class actually call SaveChanges. 

However if your child objects are always going to be children (not switchables) then you could just have your save logic only in the parent; it could check the children to see if they really changed and not bother with those or you could always just gather all the data and update the row.  Your child objects should just contain Child_Insert / Child_Update methods with no logic so you can still call FieldManager.UpdateChildren so CSLA will properly set their metadata states (such as IsDirty).

Copyright (c) Marimer LLC