Hi,

I have the following question re Philip Brown's framework:

 The framework instantiates singleton data management objs for each type of
problem domain obj (all prob domain objs uses the same data man obj, as the
data man obj is stateless). This works fine.

The framework instantiates a new data man obj for each problem domain list
object like this :

constructor TPatientList.CreateByName (Name: String);
begin
  inherited Create (TPatient, TPatientDM.CreateByName (Name));
end;

where TPatientList is of class prob domain list. You can see that the data
man obj is instantiated on the fly (second param of the inherited create
method), but a reference to the data man obj is not kept by anyone and it
seems to me that the obj is therefore not being destroyed.

Maybe I've missed something in the code, or I've missed a relevant post to
this group :-) Either way, can anyone shed some light ?

Thanks.

I was having all sorts of issues with leaking bits and pieces and ownership
etc so I switched the whole lot to using interfaces. Now it is all Delphi's
problem! I don't have to worry about it!

--
Regards

Kevin Jesshope
In Touch Computer Support
Adelaide, South Australia

Never be afraid to try something new; remember, amateurs built the Ark, and
professionals built the Titanic.

news:3ba062b6_2@dnews...

Jannie,

After much experimentation with an application based on Philip Brown's
framework I did manage to get an essentially "leak free" implementation up
and running. I must admit I did need to spend several hours with SleuthQA's
CodeWatch to achieve it. It was my first attempt at getting an OO database
connection working so I'm far from being an expert.

My understanding was that Philip Brown's framework was mainly meant as a
demonstration work; something to get you started. Yes, you are correct in
noticing that there are code "leaks" and you will need to clean it up for
any serious production work.

eg
constructor TPatientList.CreateByName (Name: String);
var
  LDMObject := TPatientDM.CreateByName (Name);
  try
    inherited Create (TPatient, LDMObject);
  finally
   LDMObject.Free;
  end;  { try/finally }
end;

Kevin's suggestion of using interfaces would probably help also, but I
haven't tried that approach. I think Philip Brown's framework was written
for Delphi 3 which does not support interfaces so at that time it was not an
option.

HTH

Steven Mitchell,
Sydney Australia

news:3ba062b6_2@dnews...

news:3ba2f15b_2@dnews...

Any chances to place the reworked framework to b.p.attachments?

Thanks,

--
Michael Beck (Team JEDI)  http://delphi-jedi.org
http://www.geocities.com/beckmi/delphi.htm

Michael,

As much as I'd like to help, I think that the process of going through and
solving these issues is often vital to gaining a better understanding of the
framework and paradigm. Besides there were very few (and minor changes)
applied to the framework itself. Most of the hard work is in getting the
problem domain objects right and these are application specific.

Unfortunately I did not spend any time on the AppointMate example other than
getting it to compile and run otherwise you would have been welcome to a
copy (assuming Philip Brown had no objections). As I wanted to test how
easily I could put together a database application I launched into writing a
Purchase Order system without using data aware controls. I chose FlashFiler
V1, which does not support SQL, for the back end. This was quite a daunting
task for me as in the past I had always used the RAD approach, at which
Delphi excels. I was pleased with the outcome both in terms of application
performance and the re-usablility potential for code so it was worth the
effort.

I'm sorry I can't be of more specific help. Hopefully there are others out
there more experienced with Philip Brown's framework who can shed more light
on the issue.

Steven Mitchell,
Sydney Australia

news:3ba3107c_1@dnews...

If it wasn't clear to everyone (I thought it was), the framework demo and
application were developed interactively during a one-day training session!
So therefore no warranties are made and there are specific warnings in the
code about it NOT being suitable for production systems.

With respect to the first question, the DM object that is constructed and
passed as a parameter should be freed by the created PDList when the PDList
is destroyed; it assumes ownership of the object.

All of the code released is completely public-domain and warranty free.
Everyone may do anything they like with the code. Obviously there are many
deficiencies in the code and the design and a production-ready system takes
a lot longer than a day to write while talking to a class of 80 at the same
time!

----
Philip Brown
Informatica Systems Ltd

No good deed goes unpunished.

Neal

Which makes the framework even more amazing.

Not that many ... I can tell you that we have changed very little of the
original framework. I can also tell you that this framework was one of the
primary reasons why we were able to introduce OO into our development
strategy. It's fine reading a book, but the code is what counts ... and this
code counts. Thank you.