I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
now wondering how it is realized/used in real world applications.

I don't believe that one would create a dataset and add relations to it and
so on for every table in the application, this would be a real mess and this
has nothing to do with OOP.

Normally, would would create a class Customer, a class Invoices, Positions,
Articles and so on.
But how can this be realized using Datasets? Datasets and encapsulating data
+ hiding implemention in classes seems to be a contradiction to me.

Sorry for me stupidness but I found no example explaining this.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

"cody" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
> now wondering how it is realized/used in real world applications.
>
> I don't believe that one would create a dataset and add relations to it
and
> so on for every table in the application, this would be a real mess and
this
> has nothing to do with OOP.
>
> Normally, would would create a class Customer, a class Invoices,
Positions,
> Articles and so on.
> But how can this be realized using Datasets? Datasets and encapsulating
data
> + hiding implemention in classes seems to be a contradiction to me.
>
> Sorry for me stupidness but I found no example explaining this.
>
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>
Actually, as DataSet is a class in the ADO.NET hierarchy, it has everything
to do with OO.
You use one or more DataSet objects in your OO solution. How you choose to
have objects from your own class definitions interact with DataSet objects
is up to you.
For example, if create an instance of your Customer class, the datamembers
of your object could be set from a given row in a table within a DataSet
object, if it made sense to do so in your scenario.
By using DataSet objects, you're taking advantage of inheritance and
encapsulation, two of the more prominent features of OO.

Peter [MVP Visual Developer]
Jack of all trades, master of none.

On Mon, 10 May 2004 01:06:44 +0200, "cody"
<(E-Mail Removed)> wrote:

>I don't believe that one would create a dataset and add relations to it and
>so on for every table in the application

Tables are not in the application, they are in the DBMS.

>, this would be a real mess and this
>has nothing to do with OOP.

Data management has nothing to do with OOP.

>Normally, would would create a class Customer, a class Invoices, Positions,
>Articles and so on.

But that is a blunder. Customers, Invoices, Articles, etc should be
tables not classes. Tables and classes are radically different.

>But how can this be realized using Datasets? Datasets and encapsulating data
>+ hiding implemention in classes seems to be a contradiction to me.

Datasets are not for that. They are for presenting the tables to the
users.


Regards
Alfredo

Cody,
Martin Fowler's book "Patterns of Enterprise Application Architecture" from
Addison Wesley discusses when to use "Data Sets" and when to create a Domain
Model. http://www.martinfowler.com/books.html#eaa

Using either Typed DataSets or untyped DataSets, is a viable Object Oriented
approached to creating solutions in .NET. In addition to the more
"traditional" Domain Objects (business objects) approach to. Martin uses the
term Table Module pattern to refer to using a DataSet.

Martin's book discusses when you should consider one over the other, plus
various patterns to support an OO approach with either (DataSet or Domain
object) approach.

For example I would consider a Table Module & Table Data Gateway approach if
my "Domain objects" did not have any real logic to them. See
http://www.martinfowler.com/eaaCatalog/tableModule.html &
http://www.martinfowler.com/eaaCatal...taGateway.html patterns

However if my "Domain Objects" had heavy logic to them, then I would use a
Domain Model and Data Mapper approach. See:
http://www.martinfowler.com/eaaCatalog/domainModel.html &
http://www.martinfowler.com/eaaCatalog/dataMapper.html patterns

Note: My Data Mappers would use a DataReader to read an row from the
database to create a new Domain object, passing the information for a row to
the constructor of the Domain object.

Hope this helps
Jay



"cody" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
> now wondering how it is realized/used in real world applications.
>
> I don't believe that one would create a dataset and add relations to it
and
> so on for every table in the application, this would be a real mess and
this
> has nothing to do with OOP.
>
> Normally, would would create a class Customer, a class Invoices,
Positions,
> Articles and so on.
> But how can this be realized using Datasets? Datasets and encapsulating
data
> + hiding implemention in classes seems to be a contradiction to me.
>
> Sorry for me stupidness but I found no example explaining this.
>
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>

Hi Cody:


"cody" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
> now wondering how it is realized/used in real world applications.
>
> I don't believe that one would create a dataset and add relations to it
and
> so on for every table in the application, this would be a real mess and
this
> has nothing to do with OOP.

I totally agree with the Mess part. It may or may not have something to do
with the OOP part. An object doesn't really care how it's properties get
set as long as the follow the accessor's rules.I konw that's not the point
you were making but that's why I say it may or may not have something to do
with OOP.

Datasets are composed of datatables and datatables are Two dimensional
objects. With DataRelations that can change quite a bit. However, there
are more than a few structures out there that don't fit very comfortably
into the Relational model.

There's a philosophy known as OR/M (Object Relational Mapping) that tends to
bridge this gap, and if you look at ADO.NET 2.0 ,there's an object called an
ObjectSpace that addresses your concerns. OR/M tools basically handle the
mapping of your object properties to you database schema (this is an
oversimplification but it doesn't change the point). Anyway, OR/M tools
sell b/c they do what is a real pain in the butt (see Messy) to do in many
instances.

But the problem is that any downside of DataSets inherent in Relational
Dataabases. I agree that it's not always clean and depending on your
requirements, you may end up shoving Square pegs down round holes but it's
the best we have.
>
> Normally, would would create a class Customer, a class Invoices,
Positions,
> Articles and so on.
> But how can this be realized using Datasets?
The devil is really in the details and the problem here is that you may have
many-to-many relationships which are a nightmare to handle with the current
model. The short answer is create four tables, link them where you can. I
can think of implementations I've worked on where this would fit right in
with the dataset model, and just as easiler think of ones that were ghastly.
It really depends on the implementation of each class, and I know that's
sounds more like an excuse than an answer, but IMHO, it's a situation where
you have to take the good with the bad.
Datasets and encapsulating data
> + hiding implemention in classes seems to be a contradiction to me.

It can certainly be but not necessarily so. Like I mentioned in the
beginning, it's not a contradiction in that the object doesn't care where
it's data comes from. A dataset whose structure can mimic the object
strucutre is a very natural fit. But I'm not going to pretend that there
aren't a bunch of situations where the implementation is awkward.

Regrettably, OOP isn't a perfect model either and not everything can be
modeled by objects (why do I get the feeling I'm opening a can of worms with
this last statement ;-) ). Rather, everything can probably be modelled,
but not elegantly. Same with DataSet.
>
> Sorry for me stupidness but I found no example explaining this.
>
I think that the result is that you need to consider the tools you have at
your disposal. For years, Joins were really costly (and still are in many
situations) in most RDMBS situations in many circumstances, but that has
nothing to do with Relational theory. On the contrary. However, the
pragmatic reality made the theoritical application a 'contradiction'...
should I normalize to xNormal form or not? So many modelled tables to
performance issues over theoretical correctness even though the theory was
totally correct.

I suspect this is a similar albiet nonidentical situation. I know this is a
bit abstract of an answer but it's really hard to get more specific without
using specific instances. I'll gladly elaborate on specific examples and I
can be a lot more clear then.

Cheers,

Bill


www.devbuzz.com
www.knowdotnet.com


> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>

Hi Cody,

In addition to Bill Ryan,

I see this often on this dotNet newsgroups. It seems that OOP is only OOP
when you make your own collections using the object methods.

I think it is something more.

For the rest I think the most is said in this thread.

Just my thought.

Cor

Peter van der Goes wrote:
>
> "cody" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> > I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
> > now wondering how it is realized/used in real world applications.
> >
> > I don't believe that one would create a dataset and add relations to it
> and
> > so on for every table in the application, this would be a real mess and
> this
> > has nothing to do with OOP.
> >
> > Normally, would would create a class Customer, a class Invoices,
> Positions,
> > Articles and so on.
> > But how can this be realized using Datasets? Datasets and encapsulating
> data
> > + hiding implemention in classes seems to be a contradiction to me.

> Actually, as DataSet is a class in the ADO.NET hierarchy, it has everything
> to do with OO.
> You use one or more DataSet objects in your OO solution. How you choose to
> have objects from your own class definitions interact with DataSet objects
> is up to you.

I hate to spoil the party, Peter, but DataSets lack a lot in the OO area.
For example, the building blocks of datasets are deep down, the datarows and
the datacolumns. There is no public constructor for the datarow. The datarow
can only be created by a datatable. This is because the cells of a datarow
are described by column objects in the datatable. In other words, you can't
use datarow objects on their own, you need a datatable and datacolumns as
well.

You can subclass the datarow, for example to add a property, but this will
create a lot of mess: first you also have to subclass DataTable to produce
your own datarow classes. Now the fun part begins. The embedded functionality
inside the DataTable is not seeing your added code. For example when you bind
to the datatable, the embedded code will completely ignore your property and
it will not show up in the bound grid. Furthermore, serializing the Datatable
will completely skip the new property.

There is also no way you can extend this code, as the methods are made
private (ISerializable is implemented private).

> For example, if create an instance of your Customer class, the datamembers
> of your object could be set from a given row in a table within a DataSet
> object, if it made sense to do so in your scenario.
> By using DataSet objects, you're taking advantage of inheritance and
> encapsulation, two of the more prominent features of OO.

I fail to see where you take advantage of inheritance when using a DataSet.
All important technology in the dataset is hidden and can't be extended. As a
matter of fact, you can't even create serialization code in the subclass you
derive from DataTable when you use VB.NET, as you can't implement
ISerializable on the derived class because DataTable implements it private
and VB.NET doesn't let you implement it again. You can in C#, by explicitly
implement the interface, however you can't call DataTAble's base class
serialization code, which means that you have to do the serialization
completely yourself.

A datatable is a container/bucket for arrays of object references (datarows)
and it contains per cell index position of these arrays 1 datacolumn object
to describe the contents of all the cells at that index in all the arrays. A
DataSet is a container/bucket for datatables and defines relations between
them via objects. DataSets and friends, although perhaps useful, are a very
bad example for OOP.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

William Ryan eMVP wrote:
> "cody" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> > I've seen an Introduction on ADO.NET with its Datasets on .NET TV and Iam
> > now wondering how it is realized/used in real world applications.
> >
> > I don't believe that one would create a dataset and add relations to it
> and
> > so on for every table in the application, this would be a real mess and
> this
> > has nothing to do with OOP.
[...]
> There's a philosophy known as OR/M (Object Relational Mapping) that tends to
> bridge this gap, and if you look at ADO.NET 2.0 ,there's an object called an
> ObjectSpace that addresses your concerns.

No, that's been removed from ADO.NET. It will be released separately.

> > Normally, would would create a class Customer, a class Invoices,Positions,
> > Articles and so on. But how can this be realized using Datasets?
> The devil is really in the details and the problem here is that you may have
> many-to-many relationships which are a nightmare to handle with the current
> model. The short answer is create four tables, link them where you can.

m:n relations are definitions of a higher abstract form, like you find in
NIAM/ORM. In the relational model, they do not exist, in there you only have
FK constraints. You can semantically define relations between elements,
however you always require 1 or more elements:
1:1 relation can be: a PK - PK relation or a PK - FK(non PK)/UC relation
a m:n relation is always build with: a 1:n and a m:1 relation. Because you
can define an m:n relation and an 1:1 relation with different elements, you
can also simply specify these elements and use them separately. For 1:1
relations this can be a real pain, and it's not hard to specify 1:1 relations
with the same logic as 1:n relations are specified because they too are
defined between 2 elements (attribute sets, living in separate tables or in
teh same table).

m:n relations are different because they require an intermediate element
where both ends of the m:n relation are related with. (order <- orderlines ->
product) The problem begins when you want to save 2 elements which are
related via an m:n relation. What to do with the intermediate element? Create
automatically or do you have to add this as well? I find it KEY that that
intermediate element is visible and has to be saved as well. Because if
that's the case, the whole relational model inside a dataset or object model
is much simpler to understand and to work with and code stays consistent.

> Datasets and encapsulating data
> > + hiding implemention in classes seems to be a contradiction to me.
>
> It can certainly be but not necessarily so. Like I mentioned in the
> beginning, it's not a contradiction in that the object doesn't care where
> it's data comes from. A dataset whose structure can mimic the object
> strucutre is a very natural fit. But I'm not going to pretend that there
> aren't a bunch of situations where the implementation is awkward.
>
> Regrettably, OOP isn't a perfect model either and not everything can be
> modeled by objects (why do I get the feeling I'm opening a can of worms with
> this last statement ;-) ). Rather, everything can probably be modelled,
> but not elegantly. Same with DataSet.



I'm with you here. DataSet objects are good at what they are for: being a
container for other containers in which data is stored which is related
(inside the table ! and between tables) based on information stored inside
the container at runtime. This is very flexible, but doesn't work in OOP very
well, where you have fixed definitions and you extend these through
inheritance and polymorphism.

> > Sorry for me stupidness but I found no example explaining this.
> >
> I think that the result is that you need to consider the tools you have at
> your disposal. For years, Joins were really costly (and still are in many
> situations) in most RDMBS situations in many circumstances, but that has
> nothing to do with Relational theory.

Joins are very cheap btw, as they can be very well optimized. Subqueries on
the other hand ARE still very expensive.

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

Hallo Frans,

A lot of text, however when I read this I have to think on the management
class, for which is much the same in my idea as you write.

When it is about dataset everybody seems to want to serialize to get an in
my idea older concept of dataprocessing.

My idea about it is that people want to keep the three tier, while I do not
see much necessary anymore for it (or better to say, it conflicts for me in
some cases)

However I place this to discuss, not because I am completly sure of it.

Before you understand it wrong, I have made applications in far past with
much more than three tiers, because I than seperated the datacom, the
database, the application, the security in seperated tiers.

So go ahead, shoot.

Cor

On Sun, 9 May 2004 22:39:08 -0400, "William Ryan eMVP"
<(E-Mail Removed)> wrote:

>Regrettably, OOP isn't a perfect model either and not everything can be
>modeled by objects

OOP is not a data management model. The known data management models
are The Network Model (with its specialization: The Hierarchical
Model) and The Relational Model.

Unfortunately many OO practicioners use the obsolete Network Model.

>On the contrary. However, the
>pragmatic reality made the theoritical application a 'contradiction'...
>should I normalize to xNormal form or not? So many modelled tables to
>performance issues over theoretical correctness even though the theory was
>totally correct.

The dilemma is due to the lack of data independence of the current
DBMS products.


Regards
Alfredo