Board index » delphi » Any simple example for this please

2004-05-17 10:08:00 AM
delphi70
I still cannot find out which way should I go or what should I do in my
learning situation:
I have one database table: Customer, has fields ID and Name.
I have a form with 2 edit boxes for ID and Name, a button to fetch the
customer name for the id value in the id edit box.
I think I need a business object or/and controller.
Can you guru just give me sample code for this simple operation so that I
can create a framework for building a bigger application for myself please ?
I am going to practice a formal/correct approach in making an appllication
storing my books.
 

"Alan" <XXXX@XXXXX.COM>a écrit dans le message de news:
40a81ed1$XXXX@XXXXX.COM...
with a DB and then create classes, they do it the other way round.
First, you need to define what your BO (business object) class looks like,
then you would normally use an OPF (object persistence framework) to
retrieve the object.
Using and ID to retrieve an object is not really the normal way to do things
either; IDs are really meant to be persistent pointers to objects. Just as
you would not normally ask a program to recover an object from memory by
explicitly mentioning its address, so you would never mention the ID of an
object in application code.
could use something like the MVP (model view presenter) framework; but this
is not a simple thing to implement, there are articles on my website on both
OPF and MVP, but be warned that these are not simple concepts and will
require many hours to iplement correctly.
www.carterconsulting.org.uk
would see :
procedure TCustomerManager.ShowCustomer;
var
custName: string;
criteria: ISelectionCriteria;
list: ICustomerList;
chooser: IChoicePresenter;
customer: ICustomer;
presenter: IPresenter;
begin
custName := 'Jones';
criteria := TEqualsCriteria.Create(ICustomer, 'Name', custName);
list := TPersistenceBroker.RetrieveCollectionForCriteria(criteria);
chooser := TCustomerListPresenter.Create; // this shows a chooser form
customer := presenter.SelectedItem as ICustomer;
presenter := TCustomerPresenter.Create; // this shows the Customer details
end;
Joanna
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
 

"Alan" wrote
within the context of a layered architecture that might look something like
this
presentation layer (forms, dialogs)
\
presentation adapter layer (MVC/MVP controllers or other adapter
frameworks)
/
business logic layer (business objects, process engines)
\
data adapter layer (OO-RDBMS translation/adapter layer)
/
persistence layer (database interface)
Where both major adapter layers are generally driven by business object
metadata (RTTI or other attribute/aspect facilities).
The intent of this layering is to provide a space (the business logic layer)
that can be modeled entirely based on the user's problem domain (the
business problem) without being distorted or compromised by peripheral
details like db choice or web/GUI interface mechanisms. This leads
(hopefully) both to more complete, correct, and focused business models, and
to loosely coupled, easily adapted interfaces and persistence dependencies:
code that is easier to write, maintain, extend, and redeploy.
The difficulty of your question is that since this architecture and intent
precede their application to any specific business problem domain,
simplifying that domain does not completely simplify the solution. Joanna
can post code that gives a quick feel for the approach and what it might
look like to program against such an infrastructure, but realistically
behind her line
If I haven't been too completely discouraging--ask whatever questions you
have and we'll do our best to be helpful; it is just that the help probably
won't come in the form of small sample applications.
bobD