Business object

TCustomer
properties
  FirstName
  LastName
  Age

Storage Broker

TCustomerBroker
functions/procedures
  SaveCustomer
  DeleteCustomer
  RetrieveCustomer
  RetrieveListofCustomers

Interface objects

TCustomerForm
(user wants to edit a customer)
CustomerBroker.RetrieveListofCustomers (for user to pick from)
...
... (let user edit data on screen.... then press ok )
...
Copy data from interface into business object.
CustomerBorker.SaveCustomer( CustomerBO )

-------------------------------------------
I don't see the big issue with this kind of design.

BO depends on nothing not related to Business Logic.

Storage Broker depends only on BO, seems reasonable, you should know
the objects you're trying to save.

UI depends on both BO and Storage Broker.  Again seems reasonable
since the UI should require the tools needed to accomplish it's
function.  To add printing, the UI would depend on a printing object.
To add encryption, the UI would depend on an encryption object.
--------------------------------
Why do so many of you think persistence is so different than these
other actions on objects?

Terry

Hi Terry,

How do you "copy" the UI data to the BO?

I done a TQuery/TField classes at VB to implement similar Delphi
functionality. My TField knows about Controls, ListBoxes, Memos (BO tied to
UI). I converted controls values (strings) to the Tfield datatype on the
fly. Something like that?

Thanks,

Luis.

Terry Pascal escribi en mensaje
<3a5b2632.422451...@newsgroups.borland.com>...
:
:

:
:

On Wed, 10 Jan 2001 15:57:24 -0400, "Luis Solar"

Each form (window) would have 2 procedures:

ObjectToUI -> Copies appropriate business object data to interface
objects

and

UIToObject -> Copies interface data to business object.

Terry

Terry Pascal <stealthgr...@home.com> schreef in berichtnieuws
3a5cbff2.527347...@newsgroups.borland.com...

I use an ObjectSource object for this, to be used just like a DataSource.
I.e. I place "object aware" controls on a form and connect them to the
ObjectSource. The ObjectSource is hooked up to the BO, like a DataSource is
linked to a DataSet. It forced me to write my own "object aware" controls,
but now I have a RAD way of building forms, while still being able to use
BOs.

Nice!... I think you have to put your BO's objects (with persistent layer
support) at the component palette?

Did you start your object aware components from the scractch? some helpful
links?

Thanks,

Luis.

Rmon Sinnema escribi en mensaje <93jjrv$q...@bornews.inprise.com>...

On Thu, 11 Jan 2001 07:04:50 +0100, "Rmon Sinnema"

An the BO's themselves know nothing about this mechanism, right?

Terry

Terry Pascal <stealthgr...@home.com> schreef in berichtnieuws
3a5dc083.36790...@newsgroups.borland.com...

Of course not. I wouldn't warn against cluttering up BOs with persistence if
I would clutter them up with UI stuff, would I? <vbg>

Luis Solar <lso...@vtr.net> schreef in berichtnieuws
93k73m$i...@bornews.inprise.com...

No, my BOs descent from TDataModule. I use an artificial construct involving
"handle" components to be able to link them design time to the ObjectSource.
This is not optimal, but I refuse to separate out the BOs into a package
just because I want design time access to them. I do have several other
components available, though, like the persistence mechanisms. But these are
not app specific.

Yes. All OA controls implement an OA interface, so you can use polymorphism
on them. The rest is pretty basic.