Databinding - Best Practice (object-oriented)

[Anthony]

Hi,

I would like to know your opinions about the best way of implementing
databinding in an application.

Let's take a simple example: we have a table called 'Employee' and we
would like to display its content in a DataGrid.

1st solution:
-Export all the Employee records from the database into a datatable.
-Bind the datatable to a datagrid.
-The user can insert/delete/edit records of the datatable through the
datagrid and we can easily save the data back to the database.

2nd solution (object oriented). Here I consider than an employee is an
object.
-Create a class called 'Employee'.
-Export all the Employee records from the database into a datatable.
-Create an instance of the Employee class for each record of the
datatable.
-Store all the instances in a collection (eg. ArrayList).
-Bind the collection to a datagrid


The 1st solution works very well and is easy to implement but is not
object-oriented.
The 2nd one seems to be the logical way of doing it (creation of a
'Employee' class etc) but involves developing much more code. Besides
it is not possible to add new employee through the DataGrid unless my
collection implements the IBindingList interface which is not
straightforward to do and also involves developing even more code.

I would tend to use the 1st solution as it's easy to implement and it
works fine but I can't help but think that it's not the right way of
doing it. For example if every time an employee is created or modified
in the DataGrid we want to do some checks (for example that the
FirstName and the LastName are different) in the 2nd solution I would
put this business logic in the 'Employee' class and I would be sure
that whoever uses my 'Employee' class will use the correct business
logic. If I use the 1st solution, I would have to use something like
the ColumnChanged event of the datatable to check what the user has
entered and therefore this business logic will be mixed with the code
of the client application which will make the code more difficult to
maintain.

My example is quite simple but you get the idea. What's the best way
of doing the above in your opinions?

Thanks,

Anthony.

 

[Tim A.]

I personally like to always use the OO approach where it's practical. You
can easily reuse the same Employee class in any future project but you can't
reuse the datatable code (cutting and pasting doesn't count for reuse).

 

[james]

Anthony,

Go to www.thona-consulting.com and take a look at their EntityBroker. This
is an OO data access layer you use instead of ADO. It uses real objects and
provides all the databinding stuff you need to do exactly what you want.

JIM

 

[Guest]

An interesting question, for sure. There's a lot of tradeoffs to consider and makes me wonder "What are you trying to achieve"? Others seem to suggest that layering your app into separate tiers is a concern, although you didn't say anything about that. If you know your app is never going to have to be used with another database, for example, then that is much less of an issue than if you need to be generic in terms of data sources. So, the objectives of your particular project come into play

I don't agree that your "1st solution" is not object-oriented. You're certainly using objects (at least one form, a datagrid, a data table, presumably a data set and/or data view and data adapter.) What is it that is not "object-oriented"

You could derive your Employee class from the Data Set. It would contain the data table your grid is bound to and the "ColumnChanged" event procedures and all that kind of thing would be encapsulated into it. If there are going to be other users of this class, they merely bind their own presentation objects to it.

You said your example is simple. In a real app, there would probably be other, related tables involved. They could also be included in this derived class, completed with constraints, data relations, etc. as nec.). Remember that the dataset is totally disconnected from the data provider

If separation from the data layer is really an issue, you could keep the Data Adapters in a separate tier. Alternatively, they could be encapsulated in the Employee object - certain connection and SQL-related parameters could be exposed. In that way, your Employee object could be usable with other SQL databases but not necessarily other data sources. It all depends on requirements

This would give you the advantages of better encapsulation and partitioning of your application, while at the same time getting the benefits of the existing methods of objects like the data grid, data adapters, etc

Another idea re your "2nd Solution": Exporting the database into a Data Table and then creating an Array List of Employee objects is redundant in the sense that it would leave you with two complete in-memory representations of the data. It would be better to use a Data Reader to retrieve the data and populate your ArrayList from the reader. If you do use a Data Table, dispose of it, or at least clear all references to it, when your done with it. Of course, if your database is small, it's not a big issue






within your own methods would handle necessary validation before comitting changes to the database and all that.
Since the dataset is disconnected from the data provider, such a derived Emplo

 

[Martin Rosén-Lidholm]

I'm also advising you (like Fowler in Enterprise Patterns) to use the OO
aproach together with an ORM with data binding support *if* you have complex
business logic. Otherwise I'd go for typed datasets and «table modules».

It all boils down to what your requirements are. If you have complex
business logic, can use a fat WinForm client, and let a framework handle the
DB schema and SQL, then I recommend you have a look at Borland's ECO.

It's a very productive tool for OO domain model driven development.

Regards,
// Martin Rosén-Lidholm

 

[Alfredo Novoa]

Let's take a simple example: we have a table called 'Employee' and we
would like to display its content in a DataGrid.

1st solution:
-Export all the Employee records from the database into a datatable.
-Bind the datatable to a datagrid.
-The user can insert/delete/edit records of the datatable through the
datagrid and we can easily save the data back to the database.

2nd solution (object oriented). Here I consider than an employee is an
object.
-Create a class called 'Employee'.
-Export all the Employee records from the database into a datatable.
-Create an instance of the Employee class for each record of the
datatable.
-Store all the instances in a collection (eg. ArrayList).
-Bind the collection to a datagrid


The 1st solution works very well and is easy to implement but is not
object-oriented.

Why not?

Datatables and datagrids are objects.

The 2nd one seems to be the logical way of doing it (creation of a
'Employee' class etc)

This is a superfluous class that does not add value.

but involves developing much more code.

Indeed, a lot of superfluous code.

I would tend to use the 1st solution as it's easy to implement and it
works fine but I can't help but think that it's not the right way of
doing it.

If it works fine for you and it is easy to implement the it is a right
way.

The problem is that ADO.NET and the current SQL DBMSs are very very
far from perfect.

For example if every time an employee is created or modified
in the DataGrid we want to do some checks (for example that the
FirstName and the LastName are different) in the 2nd solution I would
put this business logic in the 'Employee' class and I would be sure
that whoever uses my 'Employee' class will use the correct business
logic.

You can declare a constraint in SQL and it will be checked when you
call to dataAdapter.Update().

If I use the 1st solution, I would have to use something like
the ColumnChanged event of the datatable to check what the user has
entered and therefore this business logic will be mixed with the code
of the client application which will make the code more difficult to
maintain.

All the business logic should reside in the database.

My example is quite simple but you get the idea. What's the best way
of doing the above in your opinions?

The best way is to replace ADO.NET with something a lot easier and
more powerful like: www.alphora.com

The 2st solution is the worst thing you can do. It is a recipe for the
disaster.


Regards
Alfredo

 

[james]

Inline...

Why not?

Because it does not expose individual objects like Employee or Customer,
it only exposes things like DataTable, DataView etc...

Datatables and datagrids are objects.

Duh, we all understand that. The poster is talking about the DAL

This is a superfluous class that does not add value.

If Employee, Customer, Invoice, InventoryItem do not add value to you
then you probably feel real comfortable programming in C or Assembly

Indeed, a lot of superfluous code.

Yeah, int x is so much more readable than int orderTotal. C'mon OO
programming is superflous to begin with.

If it works fine for you and it is easy to implement the it is a right
way.

The problem is that ADO.NET and the current SQL DBMSs are very very
far from perfect.


You can declare a constraint in SQL and it will be checked when you
call to dataAdapter.Update().


All the business logic should reside in the database.

You must be a db Admin right ? Placing all the logic in the DB is by
far the worst way to go. This has been so thouroughly discussed elsewhere
by others much more intelligent than either of us maybe that is why you
missed it. And pray tell how can you do disconnected data if all your logic
is in the database ?

The best way is to replace ADO.NET with something a lot easier and
more powerful like: www.alphora.com

The 2st solution is the worst thing you can do. It is a recipe for the
disaster.

Tell the guys at MS and everywhere else that the 3 tier model is dead
and the 1 tier model is the way to go.

 

[Alfredo Novoa]

Because it does not expose individual objects like Employee or Customer,
it only exposes things like DataTable, DataView etc...

So what?

You still are using object orientation in your application.

OO does not imply to make mistakes like to create classes like
Employee or Customer.

Duh, we all understand that. The poster is talking about the DAL

DataAdapters, DataReaders, CommandBuilders, etc, are part of a DAL. A
silly acronym by the way.

If Employee, Customer, Invoice, InventoryItem do not add value to you
then you probably feel real comfortable programming in C or Assembly

No, it is just the contrary, I don't feel comfortable coding
supefluous code in a low level language like C# or C, if I can achieve
the same through declarative 4GL code.

C and C# are still 3GLs

Yeah, int x is so much more readable than int orderTotal. C'mon OO
programming is superflous to begin with.

OO is not for data management. To use OO for data management is a
great blunder.

You must be a db Admin right ?

No, but I studied data management theory.

Placing all the logic in the DB is by
far the worst way to go.

Only a person without a grasp on data management theory could say
that.

This has been so thouroughly discussed elsewhere
by others much more intelligent than either of us

Talk about your intelligence only.

This has been so thouroughly discussed and DBMSs were created just for
that.

maybe that is why you
missed it.

Can you give a reference?

You seem very misinformed. It is just the contrary of what you said.
DMBSs are intended enforce the business logic. This is out of question
since decades ago among the serious researchers.

And pray tell how can you do disconnected data if all your logic
is in the database ?

You probably mean how to use an application when it is disconnected to
the DBMS. The answer is easy: the applications must be connected to a
DBMS all the time you work with them.

It is like to ask how to use the computer when it is disconnected.

Tell the guys at MS and everywhere else that the 3 tier model is dead
and the 1 tier model is the way to go.

The guys at MS have a lot to learn about data management, but we are
not talking about the number of application tiers. You are missing the
point.


Regards
Alfredo

 

[Anthony]

Just to let you know that I've found this very interesting article on
the Microsoft website:
http://msdn.microsoft.com/architect...spx?pull=/library/en-us/dnbda/html/BOAGag.asp

Basically Microsoft recommends to have 4 layers (presentation,
business component, data access component, database). The classes
should be stored in the business component but not everything should
be an object.

For example imagine an Employee can work in multiple departments. You
should create a class Employee (but not a class department). The class
Employee would have a Deparments property which would return a
DataSet/DataTable containing the departments the employee works for
(which means you could easily binds it to a datagrid). On an other
hand, you can have a Department class IF you want to edit a department
in your GUI (change its name for example) but this has nothing to do
with the employee.

To go back to my original example, we should have a method in the DATA
access component which would return a dataset (list of employees) so
that you can easily bind it to a DataGrid. Then if you double click on
an employee in the GUI you would call the GetEmployee(EmployeeId)
method of the DATA access component which would return an instance of
the Employee class (of the business component). You can then bind this
Employee object to the Employee form to allow the user to make some
modifications. Once s/he has finished you would call the SaveEmployee
of the DATA access component by passing the Employee object that the
user has just modified etc.

The article is a bit long but it's worth reading it I think.

Anthony.

 

[Alfredo Novoa]

Just to let you know that I've found this very interesting article on
the Microsoft website:
http://msdn.microsoft.com/architect...spx?pull=/library/en-us/dnbda/html/BOAGag.asp

Basically Microsoft recommends to have 4 layers

3 guys at Microsoft recomend that.

To go back to my original example, we should have a method in the DATA
access component which would return a dataset (list of employees) so
that you can easily bind it to a DataGrid. Then if you double click on
an employee in the GUI you would call the GetEmployee(EmployeeId)
method of the DATA access component which would return an instance of
the Employee class (of the business component). You can then bind this
Employee object to the Employee form to allow the user to make some
modifications. Once s/he has finished you would call the SaveEmployee
of the DATA access component by passing the Employee object that the
user has just modified etc.

Very cumbersome.

The article is a bit long but it's worth reading it I think.

It is very poor. Nothing strange taking into account the "extensive"
bibliography they used to prepare the article.

Regards
Alfredo

 

[Grant Frisken]

My two cents worth...

ADO.NET is one way of mapping a relational database into an object oriented
space. For my money it suffers from the fact that it is a very thin
mapping that means your application code is very exposed to the actual
database structure. It also results in objects which are fairly
"unnatural" for purist OO designers - that is the objects "Tables, Rows"
have no real basis in the domain.

Implementing a fatter OO mapping layer does take some more work (mostly
boiler plate code) in the data layer - although there are several commercial
and free OO Relational mapping products available that do this
automatically. But I think the work is worth it because it allows the bulk
of your application to be isolated from the exact implementation details of
the data layer and makes this code much cleaner and easy to understand.

Regards

Grant

 

[Harry Maes]

You probably mean how to use an application when it is disconnected to

the DBMS. The answer is easy: the applications must be connected to a
DBMS all the time you work with them.

Imagine 10000 concurrent users which end up in 10000 active connections.
What kind of dtb are you using? What about webapps/webservices, do you use
connection pooling for that?

Harry

 

[Alfredo Novoa]

Imagine 10000 concurrent users which end up in 10000 active connections.
Ok.

What kind of dtb are you using?

You probably mean what DBMS, but I don't think it is relevant.

What about webapps/webservices

It is the same.

, do you use
connection pooling for that?

Connection pooling is a dirty trick used when connections are
expensive. But even if you use connection pooling, the applications
are connected all the time they are working.


Regards
Alfredo

 

[Alfredo Novoa]

ADO.NET is one way of mapping a relational database into an object oriented
space. For my money it suffers from the fact that it is a very thin
mapping that means your application code is very exposed to the actual
database structure.

No, you are wrong. The actual database structure is hidden by the SQL
DBMS. Your application code is not exposed to the internal data
structures used by the DBMS.

It also results in objects which are fairly
"unnatural" for purist OO designers - that is the objects "Tables, Rows"
have no real basis in the domain.

A table represents a set of true logical propositions. If the table is
well designed it has all to do with the "domain".

Implementing a fatter OO mapping layer does take some more work (mostly
boiler plate code) in the data layer - although there are several commercial
and free OO Relational mapping products available that do this
automatically.

And all of them I know make great blunders. For instance most of them
identify tables with classes.

But I think the work is worth it because it allows the bulk

I agree on that a good replacement for ADO.NET would worth the work.
The best I know is here: www.alphora.com

of your application to be isolated from the exact implementation details of
the data layer and makes this code much cleaner and easy to understand.

As I said before all DBMSs already do that.


Regards
Alfredo

 

[Grant Frisken]

No, you are wrong. The actual database structure is hidden by the SQL
DBMS. Your application code is not exposed to the internal data
structures used by the DBMS.

I meant of course that your code is exposed to the relational model - which
is in general a different way of looking at the problem domain then many OO
designers would use. This is not to say that it is necessarily better or
worse - just different - and when using object oriented design and languages
there is an impedance mismatch between the two models. ADO.NET does
nothing to address this, it just maps the relational model into objects
which results, in my view, in a somewhat unnatural object oriented usage if
you choose to use this model directly throughout your code.

A table represents a set of true logical propositions. If the table is
well designed it has all to do with the "domain".


And all of them I know make great blunders. For instance most of them
identify tables with classes.

This doesn't have to be the case. I've developed OO/Relational mappings in
the past which allow much more sophisticated mapping then one class = one
table. I agree that the tools that attempt to auto generate a relational
structure from an OO hierarchy based on such simple heuristics tend to
produce very ugly and inefficient database structures (just as I believe
direct mapping of a relational database structure into object oriented
design tends to produce ugly object oriented code). The two layers, in my
view, need to be designed somewhat independantly to maximise the strengths
of both technologies.

I agree on that a good replacement for ADO.NET would worth the work.
The best I know is here: www.alphora.com

I see you have pushed this product several times - you wouldn't happen to
have a financial interest in it would you

As I said before all DBMSs already do that.

You appear to come from a very strong DMBS background - which means that you
are probably very comfortable using this model throughout your code.
Others will prefer to work with an application model that is closer to the
design modelling that they do (which typically will not include tables,
relations and rows etc as first order objects).

Regards

Grant

 

[Harry Maes]

You probably mean what DBMS, but I don't think it is relevant.
What's in a name.

Connection pooling is a dirty trick used when connections are

So you have a server/dbms that can handle 10k of concurrent connections do
you? I would really like to see some performance figures then...

BTW, why don't you use a OO database? Probably best of both worlds for you
because implementing OO in a relational dtb sucks IMO.

HS

 

[Alfredo Novoa]

What's in a name.

Currently I am using SQL Server CE and I also used Oracle, Interbase,
Firebird, and file processors like MS Jet and Borland's BDE.

So you have a server/dbms that can handle 10k of concurrent connections do
you? I would really like to see some performance figures then...

BTW, why don't you use a OO database?

Because they are a bad idea. The called OO DBMSs are network DBMSs
with some object features. They were a backward step. It is a lot
better to add object features to relational or SQL DBMSs, like all the
major vendors are doing.

SQL Server Yukon is a good example.

The use of OO DBMSs is decreasing.

Probably best of both worlds for you
because implementing OO in a relational dtb sucks IMO.

It depends on the DBMS. For instance with Yukon you can define your
classes/domains in C# or VB.NET, and with Oracle you can use Java.


Regards
Alfredo

 

[Alfredo Novoa]

I meant of course that your code is exposed to the relational model - which
is in general a different way of looking at the problem domain then many OO
designers would use.

And it is infinitely better for data management BTW. OO designers
should learn about The Relational Model, but many of them only know
what they readed in an OOD book's appendix written by a developer
without a grasp on data management theory.

This is a vitious circle.

OO is for application development only, not for Database Systems
development. Applications are only a part of an Information System.

A typical information system has one DBMS and several applications.
The design of the whole system is very different from the design of
one of the applications.

This is not to say that it is necessarily better or
worse - just different

No, it is a lot worse. What many OO coders do is to process the files
in the applications or in specific purpose DBMSs built by them. It is
a return to the 50's. General purpose DBMSs where created to solve the
problems of that primitive approach. You can read about this on any
decent database theory introductory book.

- and when using object oriented design and languages
there is an impedance mismatch between the two models.

Indeed, but the problem is in the OO languages that are not able to
handle tables directly. You can create array variables, but not table
variables and it is a big problem.

The problem is that most language designers knows nothing about
database systems.

ADO.NET does
nothing to address this

Yes it does. It maps the result of queries into objects, but it is
rather cumbersome. You need thousands of lines for trivial tasks. The
disconnected "architecture" is a big mistake.

ADO.NET is a clear backward step in ease of use, and it has important
problems if you want to map big tables.

IMO it is the worst part of the .Net Framework by very very far.

, it just maps the relational model into objects

It is OK.

which results, in my view, in a somewhat unnatural object oriented usage if
you choose to use this model directly throughout your code.

Again OO is not for data management it is for application development
only.

OO is not well defined. It is very subjective to say that something is
a natural or unnatural use of OO. There are as many versions of OO as
practicioners.

On the other hand The Relational Model is practically unknown by the
vast majority of the OO developers. They know the basic syntax of SQL,
but they don't understand the model and the problems it was intended
to solve.

This doesn't have to be the case. I've developed OO/Relational mappings in
the past which allow much more sophisticated mapping then one class = one
table.

one class = many tables and one table = many classes is as bad as one
class = one table.

The correct equation is:

one class = one domain.

Anything else is a great blunder.

See this for a detailed explanation:

http://www.amazon.com/exec/obidos/t..._sbs_b_1/103-0442475-8991033?v=glance&s=books

I agree that the tools that attempt to auto generate a relational
structure from an OO hierarchy based on such simple heuristics tend to
produce very ugly and inefficient database structures

It is always a blunder to start with a hierarchical approach. The
hierarchical approach for data management was discarded on the early
70's because their primitivism.

Unfortunately many people continues to build their own specific
purpose network/hierarchical DBMSs misusing the SQL DBMS as a mere
transactional file manager completely hidden to the applications.

(just as I believe
direct mapping of a relational database structure into object oriented
design tends to produce ugly object oriented code).

A good mapping tool should require no or very little code.

The two layers, in my
view, need to be designed somewhat independantly to maximise the strengths
of both technologies.

Indeed. The database design must be done by a professional database
designer with a good knowledge of The Relational Model, and the
applications should be intended to present the data to the users.

I see you have pushed this product several times - you wouldn't happen to
have a financial interest in it would you

No, in fact I am developing a similar product, but it is not finished
and I can not recomend it

I believe in that approach.

You appear to come from a very strong DMBS background

My background is in OO, but I try to have a good background in
database management too.

IMO all the application developers must have a good background on data
management theory, but the reality is that most DBA's don't have it
and most coders don't have a clue.

- which means that you
are probably very comfortable using this model throughout your code.
Others will prefer to work with an application model that is closer to the
design modelling that they do (which typically will not include tables,

I am very comfortable with both, but one is clearly superior than the
other.

I solved the same problems using both approaches and the difference
was huge.

relations and rows etc as first order objects).

Tables and relations are basically the same. A table is a 2-D
representation of a relation.

The name of The Relational Model comes from the fact of it is derived
from the mathematical concept of relation: a subset of the product of
several sets.

Loosely the objects contained in a table are relationed among them.

It is a shame that tables are not first order objects in OO languages.


Regards
Alfredo

 

[Grant Frisken]

On Mon, 7 Jun 2004 09:19:32 +1000, "Grant Frisken"

OO is for application development only, not for Database Systems
development. Applications are only a part of an Information System.

A typical information system has one DBMS and several applications.
The design of the whole system is very different from the design of
one of the applications.

Here I agree with you. Its horses for courses - use the power of the DBMS
for what its good for (managing data) use the OO language where it excels
application development. I don't have much experience in OO databases but
I am willing to believe that the more traditional relational DBMS products
are much more mature and have a stronger theoretical grounding.

No, it is a lot worse. What many OO coders do is to process the files
in the applications or in specific purpose DBMSs built by them. It is
a return to the 50's. General purpose DBMSs where created to solve the
problems of that primitive approach. You can read about this on any
decent database theory introductory book.

I'm certainly not advocating attempting to manage the data in this way.

Indeed, but the problem is in the OO languages that are not able to
handle tables directly. You can create array variables, but not table
variables and it is a big problem.

Well of course you can with ADO.NET.

The problem is that most language designers knows nothing about
database systems.

I'm not sure this is the case - I just don't think this is the problem they
are setting out to solve. The integration with database systems can
typically be added as library (as with DAO, ADO, ADO.NET etc).

Yes it does. It maps the result of queries into objects, but it is
rather cumbersome. You need thousands of lines for trivial tasks. The
disconnected "architecture" is a big mistake.

It connects the two worlds but it does nothing to reconcile the two world
views. It leaves the application developer to deal with the relational
model throughout their code. The relational model is great for data
management - but not so great for application development. Using a
relational model throughout your application severely restricts the
developers ability to use some very powerful OO features (such as
inheritance, interfaces).

ADO.NET is a clear backward step in ease of use, and it has important
problems if you want to map big tables.

I agree. The last .Net project I worked on I used ADO instead of ADO.NET
for this very reason. The complete abandonment of any useful connected
model seems to be a big mistake. If you have a query that may potentially
return a large dataset then ADO.NET is hopeless because it loads the entire
dataset into memory before it can do anything else. This is catastrophic
if you have a client/server design because the entire dataset is shipped
over the wire.

Again OO is not for data management it is for application development
only.

I agree.

OO is not well defined. It is very subjective to say that something is
a natural or unnatural use of OO. There are as many versions of OO as
practicioners.

Well I agree OO is very illdefined and it is easy to get into a war of "I'm
more OO than you". But I think that there would be general agreement that
relational model lacks many of the features (such as inheritance, interfaces
etc) that make OO such a powerful tool for application development.

one class = many tables and one table = many classes is as bad as one
class = one table.

The correct equation is:

one class = one domain.
Anything else is a great blunder.

Not sure what you mean by a domain. I think you may be being a little
dogmatic.

Indeed. The database design must be done by a professional database
designer with a good knowledge of The Relational Model, and the
applications should be intended to present the data to the users.

I am very comfortable with both, but one is clearly superior than the
other.

Well I grant that the relational model is clearly superior for data
management but for application development (user interface and business
logic) I believe that an OO model is preferable.

 

[Alfredo Novoa]

I'm certainly not advocating attempting to manage the data in this way.

But OOAD books advocate this approach and it is a shame.

Well of course you can with ADO.NET.

No you can not. What I mean is that tables are not "first class
citizens" and arrays are.

What I mean is something like this:

var a relation { a integer, b integer } key { a };

a := relation { tuple { a 1, b 2 }, tuple { a 2, b 1 } };

var b relation { a integer } key { a };

b := relation { tuple { a 1 }, tuple { a 3 } };

b := (a join b) { a };

With ADO.NET you can not do anything of this.

The worst case is with operations on tables there is no way to operate
with datatablet objects with ADO.NET.

When you retrieve data to a dataset object you can do almost nothing
with it in a comfortable way.

I'm not sure this is the case - I just don't think this is the problem they
are setting out to solve. The integration with database systems can
typically be added as library (as with DAO, ADO, ADO.NET etc).

Yes, but they suffer the called "impedance mismatch". It is a very bad
solution. You need a complex network of objects to represent a table
or a database in the application.

Try to implement my 5 lines with C# and ADO.NET and you will see the
difference.

With ADO.NET you need thousands of code lines to map a few tables.

It connects the two worlds but it does nothing to reconcile the two world
views.

Indeed, what reconciles the two worlds would be to have tables as
first class citizens in application languages.

The OO world is 35 years behind the DB world on this.

The relational model is great for data
management - but not so great for application development.

It is for data management only, but all the applications have to
manage some data.

Using a
relational model throughout your application severely restricts the
developers ability to use some very powerful OO features (such as
inheritance, interfaces).

This is not true. The Relational Model is completely independent of
the inheritance. There are relational languages with inheritance and
polymorphism, and all of them have encapsulation.

IMO a good OO language must have relational features and a good
relational language must have OO features like inheritance and private
parts protection.

It would be a very good thing if we could use the same language for
all, but a language with all the features we need.

The OODBMSs try to do this but with a completely inapropriate language
for data management. They cure the disease killing the patient.

I agree. The last .Net project I worked on I used ADO instead of ADO.NET
for this very reason. The complete abandonment of any useful connected
model seems to be a big mistake. If you have a query that may potentially
return a large dataset then ADO.NET is hopeless because it loads the entire
dataset into memory before it can do anything else. This is catastrophic
if you have a client/server design because the entire dataset is shipped
over the wire.

I can't agree more. For me ADO.NET is simply unusable for complex
applications.

I use it for Pocket PC apps only because it does not worth to create a
replacement for very simple applications.

Well I agree OO is very illdefined and it is easy to get into a war of "I'm
more OO than you". But I think that there would be general agreement that
relational model lacks many of the features (such as inheritance, interfaces
etc) that make OO such a powerful tool for application development.

But IMO that agreement is based on the ignorance of what The
Relational Model really is. The Relational Model is not SQL. SQL was a
quick and dirty experiment of the 70's that never should be released.

You can have single and multiple inheritance with The Relational
Model, and even you have inheritance in SQL 3.

Not sure what you mean by a domain.

A data type. What SQL domains should be but they are not.

I suppose you know what SQL domains are:

CREATE DOMAIN name [AS] data_type
[ DEFAULT expression ]
[ constraint [ ... ] ]


Class and domains are the same.

I think you may be being a little
dogmatic.

No, it is basic common sense. The most common meaning of class is data
type (class may mean many things like most OO terms), and database
domains are data types. They are the same.

On the other hand tables are variables and it is evident that to
confuse a variable with a type is a monstruous blunder.

Well I grant that the relational model is clearly superior for data
management

This is what I mean.

but for application development (user interface and business
logic)

No!

User interface logic is application development, but business logic is
data management.

Business logic are the data integrity and data derivation rules.
Business logic and databases are indissoluble. Business logic is ALL
in database design.

The Relational Model is a direct application of mathematical logic and
it is logic to use logic for the business logic

Codd won the Turing award just for this idea.

I believe that an OO model is preferable.

With The Relational Model you can enforce the business logic
declaratively with a little fraction of the code needed to do the same
with low level procedural OO code.

For instance it would be very stupid to not declare the primary keys
of the tables and to enforce that business logic on the application
using an OO language.

The same is applyable for the rest of the business logic. OO is for
the user interface logic and for the communications with the DBMS.


Regards
Alfredo