Re: OOP - a question about database access
From: Uncle Bob (Robert C. Martin) (u.n.c.l.e.b.o.b_at_objectmentor.com)
Date: 11/06/03
- Next message: Uncle Bob (Robert C. Martin): "Re: OOP - a question about database access"
- Previous message: Uncle Bob (Robert C. Martin): "Re: OOP - a question about database access"
- In reply to: Tim: "Re: OOP - a question about database access"
- Next in thread: Costin Cozianu: "Re: OOP - a question about database access"
- Reply: Costin Cozianu: "Re: OOP - a question about database access"
- Reply: Hoff, Todd: "Re: OOP - a question about database access"
- Reply: Tim: "Re: OOP - a question about database access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 06 Nov 2003 11:46:49 -0600
Tim <nocomment@rogers.com> might (or might not) have written this on
(or about) Sat, 01 Nov 2003 19:07:46 GMT, :
>What happens when the data already exists from some other application?
Ignore it until you know what your classes and objects are, and then
fine a way to bind the existing data to those objects.
>Don't you have to develop applications where at least some of the data
>already exists?
Yes, all the time.
>It's nice to talk about object this and object that but the bottom line
>is, the data resides on databases, for the most part, and you better be
>able to produce applications that can access that data and produce the
>results the boss wants.
Absolutely. However, the other bottom line is that you must be able
to produce systems that respond well to changing requirements. It is
difficult to do this when the structure of the database has
infiltrated all the code. So we try to keep the two very separate.
>Do you tell the president of a bank that the databases he has with
>customer banking information may have to be completely reorganized
>depending on your object oriented analysis for some reporting system or
>do you make your system fit the data, if possible?
The latter; but only in the interface layer. On the application side
we have objects that suit the application. On the database side we
have tables that suit the data. In between we have an interface layer
that translates one form to the other.
>All this theory is nice but it ain't gonna fly in the real world that I
>live in.
The separation of database and application is not theory. It is a
pragmatic technique to protect business rules from database structure.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc. | unclebob @ objectmentor . com
501 N. Riverside Dr.| Tel: (800) 338-6716
Suite 206 | Fax: (847) 775-8174 | www.objectmentor.com
| | www.XProgramming.com
Gurnee, IL, | Training and Mentoring | www.junit.org
60031 | OO, XP, Agile, C++, Java, C# | http://fitnesse.org
- Next message: Uncle Bob (Robert C. Martin): "Re: OOP - a question about database access"
- Previous message: Uncle Bob (Robert C. Martin): "Re: OOP - a question about database access"
- In reply to: Tim: "Re: OOP - a question about database access"
- Next in thread: Costin Cozianu: "Re: OOP - a question about database access"
- Reply: Costin Cozianu: "Re: OOP - a question about database access"
- Reply: Hoff, Todd: "Re: OOP - a question about database access"
- Reply: Tim: "Re: OOP - a question about database access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|