RunLocal

JoeFallon1 posted on Thursday, October 05, 2006

Does it make any sense to add the RunLocal attribute to a Child BO?

I am thinking of the case where the UI asks the collection to add a child. The collection may call the Shared Method which calls DataPortal.Create to load default values. In that case, you force the call thru the local dataportal and avoid the network transport hit.

A similar question - if a Root BO is marked with RunLocal and it fetches child BOs - would they RunLocal even if they were not marked as such?

Joe

RockfordLhotka replied on Thursday, October 05, 2006

You don't use the data portal to persist child objects, so it does not make sense to apply the RunLocal attribute to any of their methods, no.

One think I'm considering as a future idea, is a "child container" abstraction, which would allow you to use the data portal (in a sense) to persist your child objects. But even if I go down that road, RunLocal still wouldn't make sense, because the child would have to be persisted within the same AppDomain as its parent - so it is the parent's DataPortal_XYZ methods that determine the physical location that the code will run for the entire object graph.

JoeFallon1 replied on Thursday, October 05, 2006

Rocky,

I am not talking about child persistence. I am talking about child creation.

Page 369 of the VB book shows the diagram of what I mean. Note that DataPortal_Create is called and the child object is sent to the server to load its default values. So my question is would the RunLocal attribute be a good thing to add to the child DataPortal_Create method if I know the default values are not coming from the DB? This assumes the Constructor is essentially empty (just has the call to MarkAsChild) and that the Shared Factory method calls DataPortal.Create.

Friend Shared Function NewChild() As Child
Return DataPortal.Create(Of Child)()
End Function

<RunLocal()> _
Protected Overrides Sub DataPortal_Create()
SetDefaults()
ValidationRules.CheckRules()
End Sub

By setting the defaults in DP_Create I can call an Overridable method. One of the FxCop rules is to not call Overridable methods from a Constructor because the fields in the next level have not been initialized yet. By letting the DataPortal create the instance we know that all fields have been initialized and calling an Overridaable method at this point is not "dangerous".

Joe

RockfordLhotka replied on Thursday, October 05, 2006

Ahh, I see what you are after.

So let me put it another way: the RunLocal attribute is always honored by the data portal. The data portal has no concept of root vs child objects - it just deals with objects by calling their DataPortal_XYZ methods. If a DataPortal_XYZ method has the RunLocal attribute, the data portal will only use the local channel.

Remember that RunLocal merely means that the called code runs in the same AppDomain as the calling code. If the calling code is already on the app server, then that's where the called code will run too. Or if the calling code is on the client, that's where the called code will run.

Rocky

From: JoeFallon1 [mailto:cslanet@lhotka.net]
Sent: Thursday, October 05, 2006 7:09 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RunLocal

Rocky,

I am not talking about child persistence. I am talking about child creation.

Page 369 of the VB book shows the diagram of what I mean. Note that DataPortal_Create is called and the child object is sent to the server to load its default values. So my question is would the RunLocal attribute be a good thing to add to the child DataPortal_Create method if I know the default values are not coming from the DB? This assumes the Constructor is essentially empty (just has the call to MarkAsChild) and that the Shared Factory method calls DataPortal.Create.

Friend Shared Function NewChild() As Child
       Return DataPortal.Create(Of Child)()
End Function

<RunLocal()> _
Protected Overrides Sub DataPortal_Create()
      SetDefaults()
      ValidationRules.CheckRules()
End Sub

By setting the defaults in DP_Create I can call an Overridable method. One of the FxCop rules is to not call Overridable methods from a Constructor because the fields in the next level have not been initialized yet. By letting the DataPortal create the instance we know that all fields have been initialized and calling an Overridaable method at this point is not "dangerous".

Joe