CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Dealing with differences between Object Model and Data Model

    rated by 0 users
    Answered (Not Verified) This post has 0 verified answers | 3 Replies | 1 Follower

    Not Ranked
    2 Posts
    jasonabi posted on Fri, Apr 17 2015 2:49 PM

    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.

     

    All Replies

    Top 10 Contributor
    4,106 Posts
    Answered (Not Verified) Andy replied on Fri, Apr 17 2015 3:16 PM

    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.

    Not Ranked
    2 Posts

    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.

     

     

    Top 10 Contributor
    4,106 Posts
    Andy replied on Mon, Apr 20 2015 8:20 AM

    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).

    Page 1 of 1 (4 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems