You would use ADO to access SQL Server, so the UI data binding shouldn't change. If you have a Data layer, the business object shouldn't change either.


>I have been reading "N-Tier Application Design" By Doug Hennig. It's
>a fine article that presents a real world scenario.
>
>So I stared thinking about transforming my applications to a multi-tiered
>design. However, consider this:
>
>
>I could create an ADO data object and a business object, and build all this
>into an application.
>
>The Business Object would know the interface of the Data Object, and the
>form would know the interface of the Business Object:
>
>Form <--> Business Object <--> Data Object.
>
>
>
>Next I could bind the data to fields by creating a form class and a textbox
>class which do the following:
>
>

>** FORM Load
>
>  ThisForm.oBizObj = CREATEOBJECT("MyBizObj")
>  ThisForm.oDataSet = ThisForm.oBizObj.GetDataSet("some SQL command")
>
>

>
>

>** Class ADOText
>
>cAdoFieldName = ""
>
>PROCEDURE Init
>
>  LOCAL cControlString
>
>  IF NOT EMPTY(.cAdoFieldName)
>
>    cControlString "ThisForm.oDataSet.Fields('" + .cAdoFieldName + "').Name"
>    This.ControlSource = cControlString
>
>  ENDOF
>
>ENDPROC
>

>
>First, I'm not completely sure the textbox class would work. Second, and even
>greater, what if I later decide to move to SQL Server as a data source. Or back
>to VFP?
>
>This would require me to go back into the form and redo the way I'v bound the data.
>The solution there is to make the textbox class smart enough to handle different
>types of data access.
>
>But if you go further on this line of thinking, changing the data access would
>also require me to re-tool my Business Object, to account for the new way of
>dealing with data. What I mean is this:
>
>If I'm currently using an ADO Data Object, a GetCustomer function would return
>a RecordSet object to the Business Object, which would pass it along to the form.
>
>But If I switch to SQL; what gets passed back to the Business Object and onto the
>form?
>
>Again, this could require more re-design and re-coding.
>
>Any thoughts?