Andy Davies wrote:
I occasionally get some stick for being a dinosaur, so I decided my next
app would be properly oop.
I have trouble deciding the build order of the layers (based on what an
object could/should know about other objects, and in particular how to map
n-tier design onto the vfp world view.
So I resorted to the web - only to find (again) that there seems to be no
consensus on what *practically* to do, all discussions seem to degenerate
into angels-on-a-pin abstract navel gazing.
Several bods (some eminent) having a tired heresy-fest here:
http://fox.wikis.com/wc.dll?Wiki~FourTierArchitecture~softwareEng
Who can fit the pegs into the holes?
Holes:
UI layer
Businees [Rules] layer
Data Management layer
Data Layer
Pegs (for this game):
main.prg
oApp / App Class
Class Libs
Proc/ Fn libs
Bizobj(s)
DataObj(s)
Cursors
CursorAdapters
Data Environment
Datasession(s)
Top Level Forms
Forms
Controls
rdbms
tables
relations, constraints, SP's
The_Programmer
Use your skill and experience to build an understandable, functional,
maintainable design using some or all of the objects provided !!!
The addition of themes, alpha transparency, voice recognition/ response,
email, braille and AI is left as an exercise for the more seriously
deranged reader <s>.
Hi Andy!
The answers to your question above:
UI Layer:
Class Libs
Top Level Forms
Forms
Controls
Data Environment
Biz Layer:
Bizobj(s)
constraints
Data Layer:
DataObj(s)
Cursors
CursorAdapters
Datasession(s)
rdbms
tables
SP's
Warning: I might be wordy here. <g>
Terms: BO = Biz Object, DO = Data Object
I still leave my main.prg as the startup program in my apps. It's there
that I invoke my oUtils (or in your case, oApp) class object as the
"global beacon" for the other layers to use as needed. I always start
by designing the database first, recognizing all of the pieces/entities
and attributes I wish to collect from the user. So design the database
first, imo. Sure, you'll make changes later, but that's where I start.
Then I design my data object (I use a PRG-based class, but some like to
use VCX-based classes). It's based on a Custom object. Years ago I
started using Session objects, but when I decided to use Private Data
Sessions in my Forms (UI), it was easier and worked better for me to let
the UI handle the session so that things flowed easier and I didn't have
to screw around with manually changing data sessions. After I design
the basic DO (named "_dataobj"), I design the DO for each table or
screen as I need as a take-off of the original DO class. For example,
if I'm going to have a Customers screen that handles Add/Edit/Deletes
for your customers table, I design a DO call _dataCustomers as a class
of _dataobj. And in that _dataCustomers class, I write code specific to
handle the Customers table.
After I write the DOs, I create the business objects (BO) to interact
with the DOs. Most of the time, they're just passing the buck between
the UI's request and the DO's response/reaction. I test each of these
independently from the command window and/or inside the top of the PRG
to ensure they work as expected. Then I design the forms (UI). The
Form.Load event invokes the BO like so:
Form.Load:
this.oBiz = newobject("_bizCustomer",".\progs\_bizobj.fxp")
...and the BO's Init event is as such to link to the DO:
BO.Init
this.oData = newobject("_dataCustomer",".\progs\_dataobj.fxp")
I like to use objects a lot to pass between for single records, but my
layers are transparent when it comes to views/cursors. So, the DO
retrieves/creates a view/cursor, and that's visible to the BO and UI. I
don't take the OOP to the n-th degree and pass everything physically
amongst tiers; for Fox-only (in the UI/BO) solutions, that's unnecessary
madness. I use "logical" n-tier, not "physical" n-tier, as my solutions
have predominately been VFP for the UI/BO. I've got the project I used
at FoxForward posted on the Leafe OpenTech forum:
http://leafe.com/forum/viewtopic.php?t=1411
...and the project I'm working on now for that same client is also
n-tier designed, but with MySQL as the initial backend. (Read: I'm
coding it initially for MySQL and when time permits, I fill in the
equivalent VFP data access methods. The projects link above was
designed for VFP primarily. If you download it, the password is nt1er,
and you should look particularly at the Admin - Suppliers screen from
the main menu--that one was fully operational for both VFP and MySQL.)
hth!
--Michael
--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
http://fabmate.com
"Work smarter, not harder, with MBSS custom software solutions!"
_______________________________________________
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
** 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.
