Your contribution please: strict use of Child_ DataPortal methods on collections

Coordinator
Nov 7, 2010 at 2:47 PM
Edited Nov 21, 2010 at 11:44 PM

The use of Child_ DataPortal methods give us the full set of Csla DataPortal features including automatic authorization, object state management, etc.

Strict Child_ DataPortal use

  1. root Get factory method => root DataPortal_Fetch (DP)
  2. root DataPortal_Fetch => child collection Get method
  3. child collection Get method => child collection Child_Fetch (DP)
  4. child collection Child_Fetch => iterate child collection item Child_Fetch (DP)

Note - Everytime you use the DataPortal it's marked (DP).

Currently CslaGenFork bypasses some of these DP calls. Once it "dives" into the DataPortal, it won't "dive in" again.

CslaGenFork DataPortal use

  1. root Get factory method => root DataPortal_Fetch (DP)
  2. root DataPortal_Fetch => child collection Get method
  3. child collection Get method => iterate child collection item Get method

Note - Everytime you use the DataPortal it's marked (DP).

As you can see, CslaGenFork method just enters the DataPortal once for the entire object graph. It should be faster and indeed it is. We will see the test case results later on.

DataPortal features and reflection

The DataPortal uses reflection and provides for a lot of invisible features, like authorization control and object state management (IsNew, IsDirty, MarkNew, MarkOld, MarkAsChild, etc). Of course when using reflection you loose some performance.

Two notes:

  1. CslaGenFork generates the autorization code when needed.
  2. When using of DataPortal factory (ObjectFactory attribute) you loose the automatic state management.

So it looks like we aren't loosing a great deal. In fact Child_ DataPortal methods are code savers: they avoid the need to hand-write a lot of code. But then again we are codegen...

Performance test

The test case was a graph of read-only objects and collections as follows:

  • ReadOnlyObject root
    • ReadOnlyCollection childList1
      • ReadOnlyObject childObject1 (22770 items)
    • ReadOnlyCollection childList2
      • ReadOnlyObject childObject2 (22770 items)

All child use ParentLoad
No authorization control was in use

Using ClassicProperty declaration mode
CslaGenFork         00.937 sec
Child_ Dataportal   01.109 sec (+18%)

Using Managed declaration mode
CslaGenFork         01.515 sec
Child_ Dataportal   01.656 sec (+9%)

Your comment please. Do you feel comfortable with the CslaGenFork code? Do you think adopting strict Child_ DataPortal is a priority? Why?

This is also on the issue tracker as work Item #298: http://cslagenfork.codeplex.com/workitem/298

Coordinator
Nov 21, 2010 at 12:55 AM

Anyone?...

Developer
Nov 21, 2010 at 9:28 PM

I am happy with the CSLAGenFork code for Lazyload=false, LoadingScheme=ParentLoad case, rather than strict child data portal.

I am waiting to test out the latest (4460) version to see the code that is generated.

Bill