Kevin,

you're definitely right. It's much more related to true OO philosophy. On 
this way you encapsulate data manipulation logic right into entities where 
it belongs to, so every object has got knowledge how to manipulate with 
data. You don't care if object is parent/child or if it can act as both.
Personally, I prefer this approach too, but as always performance 
considerations can lead us to different implementation which can in turn 
sacrifice our encapsulation and thus maintainability.

However, in some situations like you said there is a small performance 
gain involved so you shouldn't care about it as much as you should care 
about your object implementations, especially if you're using connection 
pooling so the connections are reused with every hit of children's object 
data manipulation.

As you can see, we'll end like always, with case by case scenario or 
simply said - "what's good in one case, doesn't suppose to be good in 
another".
But I also see great flexibility in CSLA.NET what is showing us that Rocky 
was just keeping on mind this fact during his development of new 
framework. That's the true strenght of CSLA.NET I believe.

Best Regards!


> I would like to say that this is the beauty of the new CSLA.Net
framework.  I'm of the camp that each class should retrieve and save
itself.  I write my classes and stored procs. under that assumption.
While there is a small performance hit involved, it is not enough to be
noticeable in *most* applications.  What I loose in performance, I gain
back in maintainability (IMHO) and the ability to use an object as a top
level object or part of a hierarchy.  So for a hierarchy the top level
object loads itself and tells all children to do the same who in turn
tell all children to do the same.  So what does this have to do with
CSLA.Net?  Well I implemented this data access strategy without a single
change to a CSLA.Net base class.  Same base classes, different
implementation.  The flexibility that we now have with inheritance is
much better than any previous implementation of CSLA.
 
Rocky purposely left the data access code to be implemented by the
object developer.  This leaves a cornucopia of different methods that
can be used, including Rocky and my strategy, even though they are very
different.  
 
If you like this one better and get the framework let me know and I will
send you examples of how my data access is implemented.  This is all
very exciting.

 
Thanks,
 
Kevin

	-----Original Message----- 
	From: Rockford Lhotka 
	Sent: Tue 3/4/2003 8:42 AM 
	To: expert_vb_business_objects 
	Cc: 
	Subject: [expert_vb_business_objects] Re: Data Access & State
Mapping
	
	

	You are correct, when data relationships get too complex to
retrieve via
	a single database call you have to make multiple database calls.
	
	Of course that is true in any scenario, not just in CSLA .NET.
	
	In a grandchild case, the child object (or grandchild collection
object)
	will typically make its own database call to get the grandchild
data.
	
	You are right about the use of a JOIN, but the amount of
redundant data
	returned from such a database call can easily become so
incredibly huge
	that it is more efficient to simply make multiple database calls
	instead. As this will vary from application to application, each
	designer will have to make this determination on their own.
	
	These issues are why I do not advocate the use of automated data
access
	layers (such as EJB or other ORM products). I very much doubt
anyone's
	commercial data access layer will intelligently adapt their data
access
	strategy based on the type and volume and structure of the data
being
	retrieved from the database.
	
	This is why, in the book, I specifically leave it up to the
developer to
	implement the data access code in the most efficient manner
possible.
	All I do is define where this code goes in each business class.
	
	It is entirely up to you to decide if you want to have each
object get
	its own data, or have the parent get the data and pass the
datareader to
	the child objects, or some other strategy of your choosing. CSLA
.NET
	doesn't dictate any of these approaches.
	
	Rocky
	
	
	> -----Original Message-----
	> From: Milan Simic [mailto:ngm@E...]
	> Sent: Tuesday, March 04, 2003 12:58 PM
	> To: expert_vb_business_objects
	> Subject: [expert_vb_business_objects] Re: Data Access & State
Mapping
	>
	>
	> Yeah, DataReader is great...
	>
	> ...but what about grandchildren and n-level relations?
	>
	> When parent (collection) loads its children with data from
second
	> resultset it passes DataReader into every single child
	> pointed to right
	> row. After the child receives DataReader and loads itself, it
	> cannot load
	> its children (parent's grandchildren) because it cannot call
	> NextResult
	> method of DataReader, since resultset of other children will
become
	> unavailable by doing that.
	> If children contains aggregation (single grandchild) this can
	> be done by
	> storing all data for children and grandchildren in the same
	> resultset with
	> INNER JOIN SQL statement, so when parent passes data from
	> second resultset
	> to the children, every child will cascade it to the
	> grandchild. But extra twist is ownership (parent-child
	> relationships), both data for
	> children and grandchildren cannot be stored in the same
resultset.
	>
	> How does CSLA.NET solve this matter?
	>
	> Best Regards!
	>
	>
	> > I'm getting very curious about new CSLA.NET and very
	> impatient to get
	> the
	> b> ook finally :)
	> I> 've read all related material on Rocky's web site and
analyse all
	> slides
	> f> rom VSLive but definitely I miss some major "parts" which
I'll
	> f> discover
	> i> n the book I'm sure. As you can guess, those "parts" are
tightly
	> related
	> t> o some specific technical issues.
	>
	> > I'll be so free to post one more subject that interests me
and I
	> > promise
	> t> hat I'm not goin' to announce myself anymore on this forum
until I
	> r> eceive the book :))
	>
	> > Actually, I'm wondering how objects are being retreived and
	> persisted
	> t> hrough DataPortal data access regarding the object itself.
	> In former
	> CSLA
	> a> ll objects knew how to load itself until we introduced
	> Buffer class and
	> s> plitted UI-Centric and Data-Centric logic.
	>
	> > They simply had all data logic implemented and encapsulated
	> and they was
	> b> ehaving in the same manner in case of parent-child and
stand-alone
	> r> elation. Every parent used to call data access method of
	> every single
	> c> hild, so every child knew how to manipulate with data
	> access by itself.
	>
	> > Using Buffer class to serialize objects from UI-Centric to
	> Data-Centric
	> o> nes and viceverse we implemented all data access logic into
Data-
	> Centric
	> o> bjects.
	> T> hat's fine but in parent-child relation, the parent was
	> responsible to
	> l> oad and save the child, it means that all children will
give their
	> state
	> t> o the parent and it will serialize it to the Data-Centric
	> object or
	> p> arent will take the data from Data-Centric object and set
	> children's
	> s> tate with it.
	>
	> > As I release, first case is much more object oriented and
	> encapsulated
	> one
	> b> ut its drawback is performance in distributed enviroment,
	> because on
	> this
	> w> ay every single object in parent-child relation will send
	> request to
	> the
	> s> erver what's very bad in distributed applications
	> especially because
	> DCOM.
	> S> econd approach will work much better because with one
	> single shoot from
	> p> arent will do everything we need.
	>
	> > But in both cases data manipulation left partitioned per
	> object. Data-
	> C> entric component would manipulate with data for every
	> single object.
	> A> ctually it will send query to database for every child.
	> Isn't it better
	> t> o manipulate with data just by sending one query which
	> RECEIVES data,
	> v> ery hard to update all children with one query :)
	>
	> > The most important is first case, because our objects in
	> CSLA.NET will
	> be
	> m> uch more like it, if I'm right.
	> I> f every object knows how to work with data and every
	> parent call their
	> m> ethods through collection I believe it will lower our
performances
	> d> irectly. Isn't it better for parent to propagate all data
	> which it has
	> r> etreived with one query, down to the children's state,
	> especially if
	> it's
	> n> -level structure than to just call every single child's
method?
	>
	> > Thanks to everyone...
	>
	> > Best Regards!
	> ---
	> Change your mail options at http://p2p.wrox.com/manager.asp or
	> to unsubscribe send a blank email to
	> 
	>
	
	
	---
	Change your mail options at http://p2p.wrox.com/manager.asp or
	to unsubscribe send a blank email to