Re: Databinding - Best Practice (object-oriented)
From: Alfredo Novoa (alfredo_at_nospam.es)
Date: 06/08/04
- Next message: lc: "Re: Retain design-time binding..."
- Previous message: Mika M: "ADO.NET with network problems"
- In reply to: Grant Frisken: "Re: Databinding - Best Practice (object-oriented)"
- Next in thread: Grant Frisken: "Re: Databinding - Best Practice (object-oriented)"
- Reply: Grant Frisken: "Re: Databinding - Best Practice (object-oriented)"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 08 Jun 2004 10:14:35 GMT
On Tue, 8 Jun 2004 08:52:37 +1000, "Grant Frisken"
<gfrisken.minusspam@optusnet.com.au> wrote:
>> 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.
But OOAD books advocate this approach and it is a shame.
>> 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.
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.
>> 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, 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.
>> > 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.
>
>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.
>> 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.
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.
>> The correct equation is:
>>
>> one class = one domain.
>> Anything else is a great blunder.
>
>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.
>> 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
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
- Next message: lc: "Re: Retain design-time binding..."
- Previous message: Mika M: "ADO.NET with network problems"
- In reply to: Grant Frisken: "Re: Databinding - Best Practice (object-oriented)"
- Next in thread: Grant Frisken: "Re: Databinding - Best Practice (object-oriented)"
- Reply: Grant Frisken: "Re: Databinding - Best Practice (object-oriented)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
