I was planning on making the generator open source so that will be no
problem.  So it sounds like if you add your logic to handle
relationships in a hierarchy we may have something interesting.  Right
now it is tied to SQL Server (I query the system tables) but that logic
could be replaced.
 
Thanks,
 
Kevin

	-----Original Message----- 
	From: T. Edward Cavanaugh 
	Sent: Tue 3/4/2003 4:29 PM 
	To: expert_vb_business_objects 
	Cc: 
	Subject: [expert_vb_business_objects] RE: Business Base
	
	

	Kevin,
	
	I'm interested in the code generation tool you created that
works with
	CSLA.NET.  I have been working with the WEO Object Builder
concept for the
	last year and have customized it pretty extensively.  I've
worked hard on
	creating the appropriate relationships between the objects based
on the
	relationships of the tables.  While there are complex
relationships that
	can't be modeled this way, it gives me a good starting point.
	
	I've implemented a few of the concepts from VB6 CSLA into the
model but
	I'm really looking forward to making it totally CLSA.NET
compliant.  I've
	extended the WEO code to work with MS Access and plan to add
MySQL next. 
	Would you be willing to share some of your generation code?  I'd
be happy
	to do the same and give you whatever enhancements I come up
with.
	
	I ordered Rocky's book on Jan 7 and it is estimated to ship on
March 7. 
	Hopefully the code download will be available from Wrox soon.  I
have
	several large projects that I'm holding off on until I can
implement
	CSLA.NET.
	
	Cheers,
	Ed
	
	> I have been using CSLA.Net for quite a while now and can
probably field
	some of your questions.  Yes, most of the code is encapsulated
in the
	base objects for the framework and you do not need to replicate
it.
	There are some things that you need to implement manually, such
as an
	Item method on your collection class (since you want to
implement it as
	having a return type of your derived class instead of your base
class.
	But almost all code and more importantly all plumbing is in the
base
	classes.  You will not be writing any serialization code.
	
	
	
	Here is what you will manually code on each class:
	
	Private members.
	
	Properties
	
	Business Methods
	
	Colleciton object's Item, Add, Create, Remove methods (since you
want
	them strongly typed).
	
	Criteria Class to set criteria of what information you want to
fetch for
	the object/collection.
	
	Data Access code (Uses the CSLA Dataportal interface.  You need
to
	Implement the Dataportal_Fetch and Dataportal_Update methods).
	
	Code to link objects together (Parent child relationships in a
	heirarchy).
	
	
	
	I have written a generator that pulls information from the
database and
	generates all the code to use the base classes based on a table
	structure except for the hierarchy code (too difficult to manage
complex
	relationships).  That makes life so much easier and I can
immediately
	focus on business logic.
	
	
	
	So what does this mean for using ADO.Net for transactional
abilities?
	Well its really not needed.  Rocky has implemented a good system
for
	this that supports multi level object hierarchies and having
multiple
	transactions within different levels of the hierarchy.  This is
somewhat
	difficult to do with ADO.Net out of the box.  Most importantly
it is
	part of the base classes.  Total code that you must modify to
implement
	this on your derived classes: none.
	
	Thanks,
	
	Kevin
	
	        -----Original Message-----
	        From: Milan Simic
	        Sent: Wed 2/26/2003 9:34 AM
	        To: expert_vb_business_objects
	        Cc:
	        Subject: [expert_vb_business_objects] Business Base
	       
	       
	
	        Hello there,
	       
	        I've noted two business base classes on your slides,
	BusinessBase and
	        BusinessCollectionBase. I suppose that they will contain
	business object's
	        mechanisms that will be used by all specialized BO
classes. So,
	I guess
	        that base logic will implement BeginEdit, CancelEdit,
ApplyEdit,
	IsNew,
	        IsDirty, IsValid and other methods and properities along
with
	their
	        implementation. We'll have really huge benefit from
inheritance
	if those
	        logic is implemented in base classes. All of us know
very well
	how many
	        lines of code was duplicated in CSLA for COM just for
this
	mechanisms
	        which all BOs were using.
	       
	        I'm wondering if it's true that majority of shared logic
will be
	inherited
	        through base BOs?
	       
	        Also, I see that you don't push ADO.NET too much into
your new
	CSLA
	        project, it's expected since ADO wasn't exposed too much
in your
	previous
	        books either. Personally I support that attitude to
separate
	those new
	        Microsoft's "toys" from encapsulated business logic.
	       
	        But since big ADO.NET marketing promotions and doubtless
very
	great
	        flexibility in OO enviroment, it interests me if there
was any
	        possibilities to exploit DataSet for object's state
management.
	For
	        example n-level undo, status tracking, parent child
relations,
	state for
	        values can be implemented through DataSet as some
wrapper around
	it.
	        I know that I may expect to get equal or even more lines
of
	plumbing code
	        with this approach. But in the same time I feel that
DataSet can
	be used
	        widely since it has got some logic which can transilate
us
	easily from
	        relational model to the some raw OO model. Ofcourse some
	additional work
	        is required to implement that raw model into BOs but is
it worth
	of that
	        at least in some heavy RAD enviroment where's OO through
BOs
	model
	        demanded? What are pros and cons regarding this solution
which
	probably
	        will be used very often, but I'm affraid that it can be
confused
	with some
	        real Business Object's logic more often.
	       
	        Thanks for your efforts.
	       
	        Best Regards!