DeleteSelf() vs. DataPortal_DeleteSelf() ??

DeleteSelf() vs. DataPortal_DeleteSelf() ??

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


david.wendelken posted on Friday, July 21, 2006

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 replied on Friday, July 21, 2006

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.

david.wendelken replied on Friday, July 21, 2006

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?

RockfordLhotka replied on Friday, July 21, 2006

Child objects Big Smile [:D]

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.

david.wendelken replied on Monday, July 24, 2006

RockfordLhotka:

Child objects Big Smile [:D]

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?

david.wendelken replied on Monday, July 24, 2006

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?

RockfordLhotka replied on Monday, July 24, 2006

That is what switchable objects do, yes.
 
However, the use of switchable objects almost always means your object model is flawed. Yes, there are a few cases where switchable objects really can make sense, but 9 times out of 10 they are a symptom of data-centric object design.
 
Rocky

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?

rrahlf replied on Wednesday, March 14, 2007

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

 

RockfordLhotka replied on Monday, July 24, 2006

Editable root objects are very common: Customer, Product, etc.
 
Any time you go to the database to retrieve a specific, singular, item by primary key, then that is likely an editable root.
 
What is far less common is an editable root collection. It is very rare (outside admin screens) to need to directly get an editable collection. Where I mostly use this template is when creating admin screens (look at the Admin\Roles class in ProjectTracker), because then the user really does need to interact with a collection as the top-level construct.
 
Rocky

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?

Michael Hildner replied on Friday, July 21, 2006

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