[Harbour-users] Re: ORMs

[dougf at people.net.au]

 I agree with Teo but with one proviso and that is that the client classes
should be largely table agnostic.  By that I mean that:

 creating say an object of class Person nothing is happening at the data
base level.  That will only happen when we choose to Write() [In my case
write is a method that handles both insert and update but that's just a
personal preference.]

 In practice I typically only need one such class but have a Blank()
method - possibly not the best of names since while most fields will be
set to blank in a typical situation some fields will have default or even
mandatory contents.  [My Blank() method is partt of the front end class.]

 The front end wouldn't therefore have a TTable Class, although the back
end might. [My current approach has a TQuery class as well as DataItem
class amongst others but no TTable class in the back end.]

 I also note that I would have multiple front end classes eg a TPersonList
Class as well as a TPersonClass (both of which hold data) then
"presentation layer" classes for desplaying that data (TPersonListScreen,
TpersonViewRditScreen) as well as classes relating to acquiring input for
those searches (eg TPersonSearchBySurname, TPersonSearchByDOB,
TPersonSearchByKey).  That sort of evolved as being the neatest IMO but I
understand (retrospectively) that it represents pretty much the pure OOP
approach (not that I am a great believer in theory).

 I guess that shows the remnants of the "three layer architecture" that
Microsoft was pushing some years back.

 Just my thoughts

 Regards
 xProgrammer