Datasets vs. OOP

[cody]

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

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 06:07:58 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

There is no n-tier 'law', so saying it is about physical tiers is IMHO
your interpretation, not 'the' interpretation, because there is none.

You could say the same about almost everything in the IT world.

But n-tier systems have two logical tiers: Client and server.

but the BL is a client of the DAL and a server to the GUI client tier :),
that's why I was saying, the differences in tiers are semantical, not
necessarily client/server

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

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 08:14:46 -0400, "William Ryan eMVP"
<do********@com cast.nospam.net > wrote:

Unfortunately many OO practicioners use the obsolete Network Model.

There are a lot of toerh misaaplications of OOP that are far more complex
than just this issue.

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.

I don't think every O/R mapper does that, only the ones following
Fowler/Evans' Domain model. (note: I don't follow that approach)

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

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 06:16:37 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

Agreed. The relational model is 'weak' when you look at it from an OO
POV:

Striking statement!

The Relational Model is the direct application of thousands of years
of accumulated knowledge in math and logic. It is the direct
application of Predicate Logic and Set Theory. Disciplines developed
by people like Aristotle, Boole, Cantor, Frege, Godel, Rusell, etc.
The Relational Model is a very solid mathematical framework.

I think that is a bit too much. Codd did most of the work, and before that,
there was mathematical theory, but not applyable to databases directly.
Agreed, most theoretical basis is founded way before Codd walked the earth,
but I find it a bit too much to give ancient mathematicans the credit for the
relational model ;)

you can't model inheritance for example without check constraints or even
values in tables.

I am afraid that what you mean is not inheritance at all.

( <- == is-a )

Person <- Employee <- Manager <- CEO
Person <- Employee <- Clerk
Person <- Employee <- Accountant

Now, if you set this up in NIAM or ORM (Halpin) you will use
supertypes/subtypes and which allow you to define relations directly to
'Manager' for example.

When you want to project this onto a relational model, you can't define is-a
relationships or supertype/subtypes. You can 'try', but it is very hard.
Nijssen/Halpin mention 2 ways:
1) flatten the supertype/subtype hierarchy and store them all in 1 table,
with all attributes of all types in the hierarchy in that table, and
attributes which are defined with a lower type than the root supertype are
nullable. Furthermore, add a column which identifies the type of the entity
in a particular row.
2) define 1 table per subtype and add an FK constraint from the PK of the
subtype table to the PK of its supertype table (not THE supertype table!)

1) requires values in its type column to interpret which type the row really
has. This is thus not modelable in the relational model: without data in that
column, there is no hierarchy, and the hierarchy is in the data, not in the
model. In other words you can't model inheritance this way, even though it IS
inheritance.
2) is close, however it doesn't symbolizes a hierarchy per se, because the FK
constraint just illustrates 'relationship between attributes' not an is-a
relationship. Retrieving a complete 'type' requires reads from 1 (person) or
more tables (rest), which is not modelable: I can read a row from 'Manager'
without the necessity to read its related row in Employee: i.e. the rows are
related but not seen as a unit, while we do see them as a unit in our
abstract supertype/subtype hierarchy.
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

[Alfredo]

On Mon, 10 May 2004 10:28:51 -0500, "Earl" <brikshoe<at>co mcast<.>net>
wrote:

Are we trolling Alfredo ;=)
No.
I have never read anything anywhere that a
reputable source would claim that the concept of "n-tier" had much if
anything to do with physical tiers.
I don't know any reputable source who writes about n-tiers. It is all
very weak.
Most folks would consider the term
"n-tier" in the context of separating the business layer from the user and
data layers.
A nonsense. It is impossible to separate the business layer from the
database layer because they are the same. What is possible is to
separate the logical database layer from the storage mechanism and
DBMSs are intended to do that.

An Application Server is nothing but a DBMS that uses another DBMS
behind the scenes as the storage mechanism. Then we have again a
client and a server. The backend DBMS used for storage is an
implementation detail. It is "encapsulat ed" and out of the logical
level.
Since those might be physically implemented all on the same
machine, "n-tier" is clearly a term to describe a logical implementation.
No, you may have many physical tiers in the same machine.
But a client-server relationship is "n-tier" also

Of course, a client-server system may have many physical tiers. If
they have more than 2 they are called "n-tier" systems.
Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 11:30:21 -0400, "William Ryan eMVP"
<do********@com cast.nospam.net > wrote:

Let's back way up here b/c this discussion is turning into something totally
different than the original question.
Something very frequent in the newsgroups.
As such, DataSets have NOTHING to do with Relational theory.
This is unfortunately true.
They may
appear to model it, they may appear to copy it's functionality, they may
even implement many of the rules, but they aren't necessarily RDBMS
structures or anything of the sort.
Nobody said the contrary. It is clear that datasets are intended to
map SQL databases, but you can do all you want with them.
To this end, I could easily employ datasets and say to hell with Relational
theory, Network model etc and still have a valid design.

Of course, but to use a network design in the 21 century does not make
a lot of sense.
Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 08:36:43 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.
I don't think every O/R mapper does that, only the ones following
Fowler/Evans' Domain model.

Which ones don't?

I only know these O/R mappers.
(note: I don't follow that approach)

Good for you!

Regards
Alfredo

[Alfredo]

On Mon, 10 May 2004 08:33:42 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

But n-tier systems have two logical tiers: Client and server.

but the BL is a client of the DAL and a server to the GUI client tier :),

But the DAL does not exist for the GUI. It is hidden or encapsulated.
That's why I said that there are only two visible logical layers.

In the case of a distributed DBMS is the same. A properly designed
distributed database should appear to the clients as a single
database. Client-Server again.
Regards
Alfredo

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 08:33:42 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

But n-tier systems have two logical tiers: Client and server.
but the BL is a client of the DAL and a server to the GUI client tier :),

But the DAL does not exist for the GUI. It is hidden or encapsulated.
That's why I said that there are only two visible logical layers.

You can have multiple tiers at the same tier level, hidden by a facade,
however the facade calls into different tiers.
In the case of a distributed DBMS is the same. A properly designed
distributed database should appear to the clients as a single
database. Client-Server again.

however these 'clients' are servers for other clients. So strictly thinking
in 'client' and 'server' is not that great. Better is: 'consumer-role' and
'producer-role' in a given 'situation'.

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

[Frans Bouma [C# MVP]]

Alfredo wrote:

On Mon, 10 May 2004 08:36:43 -0700, "Frans Bouma [C# MVP]"
<pe************ ******@xs4all.n l> wrote:

But this is an important issue IMO. For instance O/R mappers are tools
intended to apply the Network approach misusing the DBMSs as mere
storage mechanisms.
I don't think every O/R mapper does that, only the ones following
Fowler/Evans' Domain model.

Which ones don't?

mine :)
I only know these O/R mappers.

O/R mappers are IMHO for solving overhead code: how to work with data with
OO constructs. You need overhead code to make that happen.

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]

"Alfredo" <al*****@nospam .es> wrote in message
news:40******** *******@msnews. microsoft.com.. .

On Mon, 10 May 2004 11:30:21 -0400, "William Ryan eMVP"
<do********@com cast.nospam.net > wrote:

Let's back way up here b/c this discussion is turning into something totallydifferent than the original question.
Something very frequent in the newsgroups.

As such, DataSets have NOTHING to do with Relational theory.

This is unfortunately true.

They may
appear to model it, they may appear to copy it's functionality, they may
even implement many of the rules, but they aren't necessarily RDBMS
structures or anything of the sort.

Nobody said the contrary. It is clear that datasets are intended to
map SQL databases,

I respectfully disagree. If their intended purpose was to map back to SQL
databases, then what explains the tremendous support for XML and the fact
that you don't need to use a DB at all? It's a datasource that they are
meant to map back to, and that datasource can be a flat file, csv etc.

If they are clearly intended to map back to SQL Databases and aren't equally
intended to map to other data sources, then why can you use an Excel Sheet
or csv file, as flat and anti-sql as they get, Exactly like you would a SQL
DB, particularly in regard to the dataset. If anything you could make that
argument about a dataadapter, but again that's flawed because of the point I
just made.

If SQL Databases are the intended purpose, what explains the support for Web
Services, one of the highlights of ADO.NET that could write bits and pieces
of data to x number of hetergeneous data sources in part or in their
entirety? You could (and many do) write pieces of the Data retrieved form
th edataset ws for instance to an oracle/sql server/access db (which are all
obviously SQL) as well as HTML and XML Files which could be easily consumed
by say Infopath. I do it daily and it's in no way irregularl usage.

Moroever, you'll notice the word DataSource used extensively in the
documentation, not SQL Compliant Database. MS went through a good bit of
effort to draw this distinction precisely b/c it wanted to eliminate
confusion like this.

but you can do all you want with them.

To this end, I could easily employ datasets and say to hell with Relationaltheory, Network model etc and still have a valid design.
Of course, but to use a network design in the 21 century does not make
a lot of sense.

I wasn't saying it did..hence the statement Network model etc. I coudl opt
totally out of all of these particular models and used a declarative model
coupled with a any concept I want, I'm free to invent it for that matter..

Regards
Alfredo