Re: limit of lines?
From: Roman Kaßebaum (roman.kassebaumnospam_at_kdv-dt.de)
Date: 12/30/04
- Next message: mARCELO: "Re: Insufficient memory for this operation"
- Previous message: dk_sz: "Re: Update #1 and memory leaks!"
- In reply to: Joanna Carter \(TeamB\): "Re: limit of lines?"
- Next in thread: Roman Kaßebaum: "Re: limit of lines?"
- Reply: Roman Kaßebaum: "Re: limit of lines?"
- Reply: Joanna Carter \(TeamB\): "Re: limit of lines?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Dec 2004 14:11:50 +0100
Joanna Carter (TeamB) schrieb:
> Agreed, but don't let database design influence OO design, the two are not
> synonymous.
You are absolutely right.
My framework (Now I'm careful, I do not call it OO) has several rules
considering the database:
1. For every entity (table in the db) there is a class (e.g. TPerson).
2. The class has for every attribute (field in the db) a published prop.
Because of this rules there is a connection between the db and the
framework.
> So you will never use the Person class in another program ? One of the
> benefits of OO design is reuse; why re-write the same concept if it can be
> used from a class library ?
I use the person class in several programs which use the same entity
relationship model.
It is not possible to use the person class in other systems because the
person class has about 200 properties. We use it for a german pay role
system. Unfortunately german regulations a very complicated.
>
>
> Navigation should not exceed the business rules otherwise the rules end up
> being compromised.
Sorry, I meant that the field Company is a obligation field. It can not
be null in the db. This means that there is a CheckIt method in the
TPerson class which controls that.
> As I said before, do not try to model an OO system based on a RDBMS schema;
> there is what is known as an impedance mismatch which will cause exactly the
> problems you are experiencing, and more.
>
> Example :
>
> database
> Order
> ID
> Customer ID
> Date
> Total
> Order Line
> ID
> Order ID
> Product ID
> Quantity
> Unit Price
> Total
>
> object graph
> Order
> Customer
> Date
> Lines
> Total
> Order Line
> Product
> Quantity
> Unit Price
> Total
You are right. In this example the TOrder object would have a property
Customer: ICustomer and a property Lines: TOrderLineList.
Maybe it would be more elegant to manage this with a relation object.
> Note that in the object graph there are no IDs mentioned, these are implicit
> to the storage system and managed outside of the scope of the business
> rules.
Sometimes I give the object a second property like CustomerId: TId
because the access to an Id is faster than the access to an Object or
Interface.
Loading an Order will automatically load the Order Lines as the Order
> is said to be a Composition where the Lines cannot exist outside of the
> context of an Order.
I do not load the Lines automatically. I will load them if someone calls
the lines property.
> No, an OOP framework should give the facility to navigate comfortably
> through an Object Graph, not a database, otherwise it is not an OO
> framework.
Yes, you are absolutely right. This is exactly what I meant (Sorry for
my bad English).
> There is no need to cast objects when navigating a correctly defined object
> system.
Great, cast is the evil.
> So what happens when you get a bug in your auto-generated code ?
Happens rarely because it is generated, but your are right a mammoth
unit is bad.
> Or perhaps
> you want to derive from one of the classes included in that mammoth unit ?
It is vice versa: I derive in the mammoth unit from so called custom
classes.
> Take it from one who has fought, lost and won many OO design battles, you
> need to rethink your design and get away from database principles.
That's why I talk to you, maybe a bit late.
> Don't forget that a database can rely on stored procedures to handle some of
> the referential integrity and business logic; an object system maintains all
> the business logic in the object layer, merely using the database as a dumb
> storage mechanism
The framework handles referential integrity and the business logic. The
db is only a further security.
The framework has not special requirements to the db, that's why it
works with MSSQL, Oracle, Firebird and MySQL.
> Do all your testing of the code in the include file in a 'proper' unit with
> strictly typed names, using search and replace to test it against real
> types. Only once you have persuaded yourself that the code is solid, should
> you copy it to an include file, substituting the 'real' types with the
> 'marker' types.
Forget include files. Derive a TPersonList from a TEntityList and
introduce the property Person: IPerson with the get and set method.
With include files you have problems with breakpoints, testing, Delphi
search in projects, include paths in make scripts.
Another point is that the exe size grows because the code is for every
include in the exe.
-- Roman
- Next message: mARCELO: "Re: Insufficient memory for this operation"
- Previous message: dk_sz: "Re: Update #1 and memory leaks!"
- In reply to: Joanna Carter \(TeamB\): "Re: limit of lines?"
- Next in thread: Roman Kaßebaum: "Re: limit of lines?"
- Reply: Roman Kaßebaum: "Re: limit of lines?"
- Reply: Joanna Carter \(TeamB\): "Re: limit of lines?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
