By the subject I mean, what is the thought process between using:
Resource r = Project.Resouce;
versus:
Resource r = Resources.GetResource(Project.ResourceId);
As we're converting our inherited application to CSLA (a web app) we're thinking about this a lot. We've had a lot problems with invalid references where Resource may be in a session variable, but all a child DTO of another object, and a child of a child of another DTO. Yes, the design isn't great to begin with, so let's not go down the 'why' on that...fact of the matter is we got we got and have to work with it and we can't simply redesign the thing from scratch. Anyway, the session object maybe changed somewhere but none of the other references are updated; so even though they're all suppose to be the same thing, they can potentialy all be different because there in each object as a reference and the serialization process will break those references at some point...whether it be in view state or in session or just simply bad code that reassigns a variable.
So because of the multiple issues we've encountered from these references issues I've been going down the path of the only children are those that live in a list. Any parent object that has a 'thing' as a reference to the id of that 'thing' rather than that thing itself.
While this has made several things easier, it has also resulted in several more 'Exists' command objects and consequently more database calls when an object is updated. An object may have 10 child things, each of a different type, so this results in 10 'Exists' calls to the database, or an 'Exist' call everytime the property is changed...and maybe this isn't as bad of a things as I think...all these extra calls...maybe I'm thinking too much premature optimization...but I have this nagging feeling maybe I'm not doing this right...I mean if an editable root can have child objects...why am I not using them? Well that's because of the references...but I just can't help but think there's something I could be doing that is a happy medium.
Thanks in advance for your input and advice.
A child object is techically part of its parent. Conversely, the parent is incomplete without its children.
If you have objects that can exist independently - where A and B might interact, but A and B can exist on their own, then they are not parent-child.
On the other hand, if you have objects that can't meaningfully exist independently then they must be parent-child.
A good example is Order and an OrderLineItem. It makes no sense (in most apps) to create an OrderLineItem out of thin air. Such an object has no purpose in existing without a parent. Similarly, the Order object has numerous properties (SubTotal, Tax, Total, etc.) that can't be calculated without the OrderLineItem objects. It is unrealistic to have a working Order object without its children, because they are PART OF the parent.
I don't understand your Session/reference issue, but if you try to fight this definition of parent-child you'll end up with an overly complicated and hard to maintain object model, so I suggest weighing that against the cost of making your use of Session work as needed.
Copyright (c) Marimer LLC