Thanks Kevin and thanks Rocky,

I really support your view, but my question in this topic has arisen 
because many of my colleagues who see DataSet as some very short way from 
relational model to object-oriented one. Misuse of ADO Recorset in such a 
OO way was more obvious but DataSet seems object-oriented just because 
its "object" relations which it controls. Since those objects represents 
relational entities, we cannot mix them with OO business entities.
However, I entirely note that DataSet is underlying on relational model 
and therefore it cannot be used for OO entities.

Once again, guys thank you for supporting this forum.

Best Regards!


> Since Kevin nicely answered the bits about inheritance, I'll focus on
the ADO.NET question. I discuss this quite a bit throughout the book as
well, so what follows in this email is just a summary of some key points
you'll find as you read the book.

Ultimately, the question is whether to be data-centric or
object-oriented in your overall design. The DataSet is really, really
nice for building data-centric apps. Microsoft did a wonderful job with
ADO.NET and the DataSet. However, the DataSet is not designed to support
the creation of an application based on object-oriented design. A good
object model will not be relational, and unfortunately the DataSet is
very focused on supporting relational data schemes.

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

This is correct - I specifically isolate ADO.NET as much as possible by
containing all use of ADO.NET into four very specific methods in each
class. This is important because it means that future changes to ADO.NET
won't impact the bulk of your application code. Since the average life
of a Microsoft data access technology is about 2.6 years, this is pretty
critical to long-term maintainability of code.

Additionally, a decent percentage of applications use data from multiple
data sources (various databases, xml files, mainframe files, etc.).
Relying entirely on ADO.NET makes it difficult to deal with those more
complex scenarios. Containing all data access code in four methods of
your own design allows you to easily mix and match ADO.NET with any
other data access scheme you might need.

It also allows you to entirely avoid ADO.NET. Many organizations
implemented meta-data driven data layers to shield themselves from ADO.
I expect we'll see similar concepts for ADO.NET. Again, it is as easy to
interact with a home-grown data abstraction layer as it is with ADO.NET
and still fit entirely within CSLA .NET.

Here's some more info from my web site:

http://www.lhotka.net/Articles.aspx?id=b99dfec2-c079-4b85-98df-ea3582c28
386


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

Unfortunately this is not true. The DataSet supports limited undo - not
n-level undo. It would be very difficult to get the DataSet to do true
n-level undo in the way that CSLA and CSLA .NET support the concept.

There is also the problem that the DataSet supports a relational model,
not an object-oriented model. It would be difficult (though maybe
possible) to misuse the DataSet in such a way that you could get it to
emulate an object-oriented model, but that seemed like a lot of work to
me...

A classic example is a many-to-many relationship. The DataSet would
model this using a relational scheme, but the proper object model is
quite different. The fundamental question here hasn't changed from ADO
and VB6, so to a large degree the following article still applies:

http://www.lhotka.net/Articles.aspx?id=ff226256-903f-4aee-a921-8b09ef409
01b

You'd end up writing a lot of plumbing code or a lot of dynamic
object-relational mapping code to compensate for the different models.

And then, (in about 2.6 years) you could rewrite all your code to work
with version 2 of the DataSet. Not the route for me :)   I've already
rewritten apps 3 times to go from DAO to RDO to ADO...

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

The great thing about .NET is that most of the RAD support also exists
for business objects as well. In particular, data binding works against
objects just like it does against a DataSet - a fact I rely on quite a
lot in the book.

Here is some info on data binding:

http://www.lhotka.net/Articles.aspx?id=91e15def-fa1c-4236-86b5-b204bfc4a
0aa

Rocky

Rockford Lhotka
Author of 'Expert One-on-One VB.NET Business Objects' (Wrox Press)
rocky@l...    http://www.lhotka.net