Re: Databinding - Best Practice (object-oriented)
From: Grant Frisken (gfrisken.minusspam_at_optusnet.com.au)
Date: 06/07/04
- Next message: Doug Forster: "Re: Visual Inheritance: What Gives?"
- Previous message: Steve Sargent: "Re: activating windows from a separate thread - chat_window_activation_code.cs (1/1)"
- In reply to: Alfredo Novoa: "Re: Databinding - Best Practice (object-oriented)"
- Next in thread: Alfredo Novoa: "Re: Databinding - Best Practice (object-oriented)"
- Reply: Alfredo Novoa: "Re: Databinding - Best Practice (object-oriented)"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 8 Jun 2004 08:52:37 +1000
"Alfredo Novoa" <alfredo@nospam.es> wrote in message
news:40c4481f.1856619@msnews.microsoft.com...
> On Mon, 7 Jun 2004 09:19:32 +1000, "Grant Frisken"
> <gfrisken.minusspam@optusnet.com.au> wrote:
>
> 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.
>
> > 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.
I'm certainly not advocating attempting to manage the data in this way.
> > - 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.
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).
> > 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. 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.
> >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.
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.
> >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.
Not sure what you mean by a domain. I think you may be being a little
dogmatic.
> > 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 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.
- Next message: Doug Forster: "Re: Visual Inheritance: What Gives?"
- Previous message: Steve Sargent: "Re: activating windows from a separate thread - chat_window_activation_code.cs (1/1)"
- In reply to: Alfredo Novoa: "Re: Databinding - Best Practice (object-oriented)"
- Next in thread: Alfredo Novoa: "Re: Databinding - Best Practice (object-oriented)"
- Reply: Alfredo Novoa: "Re: Databinding - Best Practice (object-oriented)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
