v2.0.2
The template EditableRootList makes reference to item.DeleteSelf().
The template EditableRoot has no such method in it. That's a bummer, to say the least. It does have a DataPortal_DeleteSelf() routine which obviously is intended to serve a similar purpose.
However, it makes me a bit concerned to have another class call a Data Access Layer (DAL) method in my business object.
So, should the EditableRootList template have called DataPortal_DeleteSelf() instead, or should the EditableRoot template have included a DeleteSelf() method that just calls the DAL method, or am I missing something?
RockfordLhotka:The reason for this is that EditableRootList must contain child objects. A child BusinessBase-derived object would come from the EditableChild template, which defines a Friend/internal DeleteSelf() method specifically to be called by the parent object.
Um... That confusalates me to no end!
(Confusalate is a highly technical term in my part of the world.)
I just assumed that EditableChildList contained child objects and EditableRootList contained root/parent objects.
So, if EditableRootList contains child objects, what does EditableChildList contain?
Child objects
I think I was pretty clear in chapters 6 and 7 (and I think chapter 2) that you can only have one root object, and everything else must be a child. A root object forms the top of a conceptual "transaction" in memory, and a root has a containment relationship with all the other objects in the graph.
You can have a root object, or a root collection, but only one per object graph.
Then you can have as many child objects as you choose - some of which might be parent objects that have their own children. But if that parent object isn't the root object, then it is also a child.
RockfordLhotka:Child objects
I think I was pretty clear in chapters 6 and 7 (and I think chapter 2) that you can only have one root object, and everything else must be a child. A root object forms the top of a conceptual "transaction" in memory, and a root has a containment relationship with all the other objects in the graph.
You can have a root object, or a root collection, but only one per object graph.
Then you can have as many child objects as you choose - some of which might be parent objects that have their own children. But if that parent object isn't the root object, then it is also a child.
You'll have to admit that your book - well written as it is! - is a lot to bite off and chew. I'll look thru those chapters again. It won't be the first time, either!
What I understood you to just say is the only time I would use an editable root template is if I was never going to put it into a csla collection class? That would make that template pretty rare to use?
And that's why "switchable" objects are useful? Because they could be a root when you need one, or a child when you need one?
And that's why "switchable" objects are useful? Because they could be a root when you need one, or a child when you need one?
This is an interesting discussion, and it comes down to English grammar usage. The name EditableRootList is ambiguous in it's adjective use. It could mean either a List of Roots which is editable, or a List which is a Root and is Editable - "Root" being a noun or an adjective, repectively. Somewhat less ambiguous is "RootEditableList" which more clearly places "Root" as an adjective describing the list - a List which is both Root and Editable - but that doesn't fit well into the CSLA naming conventions which places the emphasis on whether or not the object is Editable over whether or not the object is Root or Child. Although it may cause some confusion, it's a completely academic argument and doesn't affect how much the CSLA kicks ass. [gramatical error intentional]
What I'm more interested in, is why the SwitchableObject template doesn't have a DeleteSelf()...but that's in another thread. ;-)
What I understood you to just say is the only time I would use an editable root template is if I was never going to put it into a csla collection class? That would make that template pretty rare to use?
You're not the only one to assume first off that an EditableChildList contains EditableChild objects and and EditableRootList should contain EditableRoot objects.
I asked something very similar just yesterday on the CodeSmith for CSLA gotdotnet site. Was going to post a link, but it looks like gotdotnet is having troubles right now.
Copyright (c) Marimer LLC