John,

I've been developing a VFP 3-tier framework for three years and asked the same questions you are asking now. We run against a mix of VFP, Oracle and MS SQL Server data sources and here are a few things I've done.

1) Use arrays for Combo Box's RowSourceType and create a .aRowSource property on your combo boxe base class. Create a lookup object with a method for each combobox. The lookup object is loaded by the application object and made accessable to all forms. The lookup object acts as a data manager for all combo boxes, decreases network traffic and increases application performance since the lookup cursors only need to be loaded in one place rather than loading for every combobox. Each lookup object method is passed a object reference of the combobox and looks something like this:

PROCEDURE dropdown_clockid
LPARAMETER toCombo,tlRequeryData
LOCAL lcWhere

IF tlRequeryData
  THIS.oAll_Clock.REQUERY()
ELSE
  IF THIS.oAll_Clock.nReccount = 0
    THIS.oAll_Clock.REQUERY()
  ENDIF
ENDIF

WITH toCombo

  lcWhere = .cWhereClause

  IF EMPTY(lcWhere)
    SELECT ID,NAME,managerid ;
      FROM oAll_Clock ;
      ORDER BY ID ;
      INTO ARRAY .aRowSource
  ELSE
    SELECT ID,NAME,managerid ;
      FROM oAll_Clock ;
      ORDER BY ID ;
      WHERE &lcWhere ;
      INTO ARRAY .aRowSource
  ENDIF
ENDWITH
ENDPROC

The lookup object should also be used to retrieve record set objects of commonly used data. This works great for passing data to different data sessions(business objects). Again it gives me a central location to access data used throughout my applciation rather than loading individual cursors for each data session. These methods look much like this:

PROCEDURE getrs_clock
	LPARAMETER tcID,tlRequeryData
	LOCAL oRS
	IF tlRequeryData
	  THIS.oAll_Clock.REQUERY()
	ELSE
	  IF THIS.oAll_Clock.nReccount = 0
	    THIS.oAll_Clock.REQUERY()
	  ENDIF
	ENDIF

	THIS.oAll_Clock.INDEX('id','ClockID')
	IF SEEK(tcID,'oAll_Clock','Clockid')
	  SELECT oAll_Clock
	  SCATTER NAME oRS MEMO
	ELSE
	  oRS = .NULL.
	ENDIF
        RETURN oRS
ENDPROC

>Since, I UI layer should not access the data directly, should my business >object responsible to to this?

One way of doing this... Create a .oData property on your business object. The UI layer updates the business layer via a oData property. The business object is responsible for populating the oData property using SCATTER NAME and for updating the data layer with data from the oData property.

IMO, if you are developing all tiers in VFP use 3-tiers only if you need 3-tiers.

1)Use a business layer to perform some special data processing (a transaction that docks another transaction and updates an employee's time bank).

2)Don't use a business layer for an interface to update employee's birthdays. Instead give them a grid bound to your data object's cursor.

My framework consists of a data, business and interface layer class. The business class is also acts as the data environment for forms. When used as a form's DE the business class DataSessionID is set to the form's DataSessionID. The advantage when used as a form's DE my interface class controls have access to the data object's cursor since they share a data session. This allows me to bind controls (grids) to cursors but still control updating data using the business class API calls.

I know some people are going to say you shouldn't access the data layer from the interface layer - it breaks design. I see it as taking advantage of the flexibility of VFP.

Will

>Hi,
>I am beginner of 3-tier development. I am trying to develop my own business class base on what i have read from web and magazine.
>
>I am using vfp native data in my deveopment and run under LAN.
>I have some question here:
>
>1. In my form, I may need to display some records in grid or combo box for user selection. Since, I UI layer should not access the data directly, should my business object responsible to to this? Convert the result from cursor to ADO or XML, then convert it back?
>
>Thank you