I use two objects in all my apps, an admin object and a data object.
The first one takes care of everything that is common to all forms in the
app, for instance, put special notices on the screen while a process is
running, or procedures that check passwords, or arrays with all the names of
the provinces in my country, or error capturing, or date validation, or
anything that has to do with repetitive chores that all apps must do.
The data object takes care of things like the one you are describing,
namely, open a database, fetch records, transform cursors into xml or read
xml back to cursors, save data, create transactions, create collections to
use in lieu of xml, etc, etc.
I stick them on the screen object with code like this in the main program of
my app:
if !pemstatus_screen,'oAdm',5)
Try
_screen.NewObject("oAdm","admobj")
Catch to oException
MessageBox(oException.message+Chr(13)+'admobj')
lError = .t.
endtry
endif
if lError = .t.
Quit
EndIf
The same code is used to place the oData object on the screen. This way,
both objects are available for use by all forms in my app.
I also use prg files to store special classes, that are only of use to the
particular application . These usually have to do with special business
rules for the particular company.
As an example, one of my clients manufactures girls and young women clothes.
Since there are many sizes and colors for the same item (i.e. a skirt) , he
needs to have a special grid made to look at stock quantities held in the 5
stores the company has in different cities, in such a way that, when the
user clicks on any cell of the grid, the stock of that item in that color
and size appears in a second grid.
The class is derived from the textbox base class and all the code described
above is in its click event. When the grid is instantiated, the textboxes in
all columns are replaced by this special textbox.
It is a bit complicated but the point is that this class, which is only of
use to this particular company, will not be placed in either the data or the
administration object. So I keep it in a separate prg file.
So, it all depends on how you want to standardize your routines.
Bye
Rafael Copquin
----- Original Message -----
From: "Matt Slay" <[email protected]>
To: <[email protected]>
Sent: Thursday, August 13, 2009 2:50 PM
Subject: Business Objects - calling code in Procedure files?
>I have created some Business Object classes, and now I am creating methods
> on them that can be called.
>
> For instance, I have a Job business object, that will have a method called
> .GetItems(tcAlias) which will fetch the child records and place them in
> the
> passed-in alias/cursor name.
>
> Now, I already have an old procedure that I've had for years in a
> procedure
> file that accepts a JobNo and an Alias and it does the same thing that I
> am
> wanting the Job object to do.
>
> So, I am wondering if it is a bad practice to let the call to
> Job.GetItems(tcAlias) just make a call to the existing procedure to get
> the
> work done? That way I have the best of both worlds where I can call the
> procedure in some places where I do not go the BO route, but I can also
> call
> the BO method when I am going that way.
>
> So, Job.GetItems(tcAlias) would just make call like
> GetJobItems(this.JobKey, tcAlias), and that's all he would do. Otherwise,
> I
> would copy-paste the code from the procedure into the BO method, and then
> I
> would have the code in 2 places! Or I could refactor my app to remove the
> procedure and force myself to use BO's everywhere, but that is a good
> chore.
>
> So it boils down to deciding if it's OK for the BO to rely on a procedure
> file to get his work done, or if he should be fully independent and have
> all
> his on code in his methods?
>
>
>
>
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/c414a5deee3f4fbf9786166592f0a...@rafaelnueva
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
