Basic Concepts - Large ED Root, should I make 1:1 Children?

Basic Concepts - Large ED Root, should I make 1:1 Children?

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


dmo145 posted on Wednesday, March 19, 2008

First off, this being my first post let me thank everyone on this forum who's contributed in the past. This place has served as a fantastic resource for me as I've been getting started with Rocky's awesome framework.

Background:
I've been messing with the framework for a little while now and I'm still having a really hard time wrapping my head around this situation. In my object model I have a "Job" Editable BO. It's responsible for persisting a valid Job. This object is rather large and getting hard to deal with (# of properties are high). Job can logically be composed of some sub objects (i.e. a jobLocation object - responsible for saving a  valid job location). These objects would not have their own identity's and would have a 1:1 relationship with the root job bo. Currently, the root is responsible for validating and saving these "would be" sub objects.
 
Question:
Should I make these logical groupings Editable Children and implement validation, authorization, data access in them? Or should I make these groupings value objects and do all the business logic in the parent job class? Or should I just leave them "as is" in the root and find some other way to deal with the size?

The editable children approach seems best to me from a design perspective, but from an implementation perspective I worry it might be more difficult in the area's of databinding and data access. I haven't really seen any examples where children are 1:1 with their roots. Any advice from the trenches would be greatly appreciated.

pillesoft replied on Wednesday, March 19, 2008

i have some similar problem ...
please check post http://forums.lhotka.net/forums/thread/22100.aspx
in my case there is also 1:1 relation
but unfortunately still no time to check the examples in detail, so i will watch your answers too, and if you find sg usefull let me kno. i'll do the same.

Ivan

ajj3085 replied on Wednesday, March 19, 2008

One option would be to have child objects which are used behind the scenes.  The root becomes a facade object, but you can split your implementation to different classes.

dmo145 replied on Wednesday, March 19, 2008

pillesoft,

I'll let you know what I end up doing. 

ajj3085,

Ah, I see. Thats not a bad option. Though I was trying to avoid having a root with a flattened hierarchy (I hate having properties like prefixes like LocationState, LocationCity, etc) that option would definitely help simplify management of my auth and val rules.

What about data access? Good db design results in me having 1 table for all these objects. But I think I would like each object to be responsible for its own data. When distributing this responsibility it always results in many hits to the same table. While its probably a tradeoff for the logical simplicity, I could just be using a poor design. Anyways, any suggestions on how to handle the da? Should I build/save these objects in the root, or, from you're experience, would I be better off distributing this intelligence so that each child can save load itself?

Again thanks for the help, any other suggestions are great!

Copyright (c) Marimer LLC