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

[Earl]

One of my clients (who used to be a CFO at a big software house) often
states that "software is an opinion". Being conceptual, the entire "layer"
idea must be -- by definition -- a logical implementation.

I do agree with the the thought that "you may have many physical tiers in
the same machine."

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

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

[Guinness Mann]

Jay B. Harlow [MVP - Outlook] wrote:

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

Hear, hear! All "business logic" is not necessarily what we
traditionally think of as "business" related. Even when it is, it often
isn't tabular. Think about a manufacturing application that has to
handle bills of assembly. The domain objects will almost assuredly
form some kind of tree structure while the native database
implementation will just as assuredly be tables.

In such a case the business objects will probably follow the composition
pattern using a data mapper to create each node.

The whole world isn't invoices and inventory.

-- Rick

[Alfredo]

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

I think that is a bit too much. Codd did most of the work
Of course. Codd had the genial idea of applying thousands of years of
advances in maths to the data management field and it has an inmense
merit.
, 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 ;)
Of course, I completely agree with you. But I was talking about the
origins of The Relational Model's strength.

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

But NIAM and ORM are not relational. BTW I never have found them very
useful.

With The Relational Model you have to represent all these information
in several relations (tables). But it is not inheritance. It is an
application of Predicate Logic. Each relation (table) represents a
predicate and each tuple (row) a logical proposition.

Table inheritance does not make sense in The Relational Model. And it
is completely different to the OO class inheritance.
When you want to project this onto a relational model, you can't define is-a
relationship s or supertype/subtypes.
Wen you project this onto a relational design the ORM types and
subtypes don't make sense anymore. You have to work in terms of
predicates and propositions.

You can define is-a relationships in many ways.

For instance:

create table IsA(name varchar(20), position varchar(20), primary
key(name, position));

insert into IsA values ('John', 'Manager');

This tuple means that John is a manager.

Relationships are relations and The Relational Model is all about
relations!

Another way:

create table Managers(name varchar(20) primary key);

insert into Managers values ('John');

This means: John is a manager.
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.
Horrible practice that breaks The Relational Model. The result is not
a relational design.

BTW "flatten" does not make sense if you are talking about The
Relational Model. Predicates and propositions can't be flat.
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!)
One table or more than one. But you can skip ORM and to do that
directly thinking in relational terms.
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 .

The relation predicates might simbolize anything you want. The FK
constraint is just an integrity constraint. An is-a relationship is a
relation like any other. They are trivial to represent with The
Relational Model.

create table Employees(Id integer primary key, name varchar(20) , wage
numeric);

create table Managers(id integer primary key, department varchar(20),
foreign key (id) references Employees(id));

insert into Employees value(1, 'John', 50000);

This means: John is the employee with the Id 1 and earns 50.000. And
of course it stablishes that John is-an employee.

insert into EmpManagers values (1, 'Accounting');

This means: the employee with Id 1 is the manager of the accounting
department.

From these two propositions you can infere that John is-a manager. And
the DBMS too, if you declare the inference rules:

create view Managers as select * from Employees e, EmpManagers m where
e.Id = m.Id;

Select * from managers.

This should return:

Id Name Wage Department
-------------------------------------------
1 John 50000 Accounting

This means John is an employee, has the Id 1, earns 50.000 and he is
the manager of the accounting department.

Regards
Alfredo

[Alfredo]

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

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.

I agree it is not very good terminology.
Better is: 'consumer-role' and
'producer-role' in a given 'situation'.

I prefer applications-DBMS
Regards
Alfredo

[Alfredo]

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

Which ones don't?
mine :)

I will look it.

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.

This is again the problem of the lack of precise terminology.

According to your definition ADO.NET could be considerd an O/R mapper.
And I don't see any problem in that.
Regards
Alfredo

[Hani Atassi]

Just a thought..

I did OOP represenation of a dataset before using DataViews.. Basically, my classes holds views of the data in a dataset using both DataView and DataRow..
There are problems with this though in the case of serializing because DataViews cannot be serialized..

Regards,