N-Tier design questions

[bernardmanning]

Hi I'm about to begin work on developing a new application which want to produce using n-tier design. At the moment it's very much at the concept stage...

we will be using vfp 8.0 and are planning to use the cursoradaptor class to access the data. The data could reside on sql server or native foxpro tables.

We are planning to use foxpro as the data access,business and UI layers. At some point the UI layer may change to something else, .net winform for example.

Initially all these tiers will be wrapped up in one foxpro application, so it's more of a logical n-tier design.

However I want to design this with moving to a physical n-tier design in mind.

In order to do this we would have to have a mechanism to transport the data from the data,biz to the UI tier.

we cannot do this using foxpro cursor as they cannot pass across the com boundary.

Two options open to us are XML or ADO.

We have the pontential for large record sets being used so I'm tending to shy away from XML.

Does anybody have any experience using ado or anything else to pass data between these tiers?

any help / pointers would be appreciated.

Many Thanks, Bernard.

 

[craigber]

If you want to engineer this to be use with .NET in the future, then XML is the only choice.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[Mike Lewis]

Bernard,

Although I don't agree with Craig when he says that XML is the only choice, I do agree that it is preferable. It is inherantly simpler than ADO, and more likely to be more widely supported in the future. However, I take your point about large data sets.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[bernardmanning]

Thanks for the quick reply guys,

So just further labour this point,

if I need to translate my foxpro based recordset to XML in order to pass it between tiers, isn't that going to cause performance problems, especially with large datasets?

or do we have to move to another kind of interface, ie instead of returning 10,000 records at one go the biz object requests the first 100 records from the data tier and then the next 100 records as the user interface requires them?

Please could you clarify for me that I would have translate my recordset to and from XML at each tier?

Again many, thanks although this is a strongly touted design methology in foxpro there does seem to be very few real world examples of how best to do this.

Cheers, Bernard

 

[Mike Lewis]

Bernard,

if I need to translate my foxpro based recordset to XML in order to pass it between tiers, isn't that going to cause performance problems, especially with large datasets?

I would think so. I've not seen this issue discussed much, but it seems to me that XML will inevitably take up more space than native Fox data, so the files will be larger, so the transfer will be slower.

At least, that's my assumption. Maybe all the extra overhead of XML won't make that much difference. I'm not sure.

Mike



Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[bernardmanning]

I guess I'll need to write a prototype in order to test the performance of converting records to xml and back again...

From what I've read the drop in performance is more than made up in flexiblilty and maintainability, but I'm not sure the users of the system would agree !

Does anybody know how the commercial available frameworks approach this problem??

Again, Many thanks, Bernard.....

 

[wgcs]

What handles each tier? (I know: you said it's all on VFP now, but in the future?)

As you're aware, the choice of data communication format determines what platform can handle each tier.

If you're guaranteed that VFP will be the middle tier and the Data tier, then you can use FILETOSTR()/STRTOFILE() and just hand free-tables (.DBF files) back and forth (limited to 16MB).

If it's between the front end and middle tier you're concerned with, I'll bet the "front end" will always be VFP, and the middle always VFP: If you go to the web, the Browser is a "pre-front end", then VFP.DLL's can handle the Web Server side, themselves accessing a VFP middle tier, and it accessing whatever data-tier... In this case, you still can hand DBF's between the "front end" and the "middle tier"

so, VFP will always be there to intecept the .DBF's. The VFP to data-tier communication will be determined by the data-tier: if an RDBMS like Oracle/MySql/Firebird/SqlServer, then use OleDB/ODBC, whichever you prefer (I prefer ODBC SqlExec commands). If the Data-tier is VFP and remote, you can use OleDB or ODBC or filetostr(.DBF)'s.

However, if the Data tier is VFP, and the middle tier is VFP, then they are probably running on the same computer, and you can just use cursors: don't separate the data tier from the middle tier with COM.. make the data access object a member of the accessing object, so that the cursors the data access object creates are in the same Data session, and accessible.

These suggestions are my opinion from my experimentation... YMMV.

 

[craigber]

Mike:
If the plans are to move this to .NET in the future, then XML IS the only solution. .NET used ADO.NET, not ADO...and they are very different animals.

wgcs:
While you can just create cursors in the data tier and then use the same cursor name in the UI, it does bind the UI to the data tier. To make them truely separate, you should pass the data from one tier to the next and not worry about what it's called.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[Mike Lewis]

Bernard,

I guess I'll need to write a prototype in order to test the performance of converting records to xml and back again...

Let us know what you discover.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[bernardmanning]

Thanks for all the input...

We really want to design this app with one eye on the future with .NET definitely being a major consideration, so thanks to Craig for all his input.

Wgcs raises a good point, one I had considered, in the that if the data and biz tier are foxpro then just pass the object reference to the data.

I think initially the tiers will not be separated physically but logically.

However, what I'd like to do now is to design this in such a way that if we did have to physically pull the tiers apart then we be in a good position to do so.

I'm surprised that after searching on this forum, wikis, the universal thread and MSKB that I've found so little real world example of this kind of architecture. Maybe I'm looking in the wrong place!!!

Does anybody have any idea as to how the commercial frameworks handle this issue?

Are most of the frameworks set up for logical separation rather than physically separation.

I suspect Com codebook caters for this physically separation.

Anybody got any further ideas or info?

Thanks again, Bernard.

 

[badukist]

Just few words:
"Complex question, complex answer"

Check this link (with many links also), I was scared

http://www.dbpd.com/vault/9802feat.htm

 

[camig1]

If the plans are to move this to .NET in the future, then XML IS the only solution.

I`ve been working with remote views in the middle tier. The remote view with parameters produce a cursor which I convert to xml with cursortoxml(mycursor,'myXMLvar') then I return myXMLvar to the UI tier, as I show you below.

FUNCTION get_clients ( lcName as string ) AS STRING
TRY
LOCAL lcXML
SELECT 0
*****/lcName is the view`s parameter/****
USE vr_clients_list
=CURSORSETPROP("Buffering", 5, "vr_clients_list&quot
SELECT vr_clients_list
CURSORTOXML('vr_clients_list', 'lcXML',1,0,0,'1')
USE vr_clients_list

CATCH TO loException
IF loException.ErrorNo=2071
lcMessage='Error:'+' '+loException.UserValue
ELSE
lcMessage='Error:'+' '+loException.MESSAGE
ENDIF
FINALLY

ENDTRY

RETURN m.lcMessage
ENDFUNC


or when you want create a new record ....

FUNCTION create_box (lcXML AS STRING ) AS STRING

LOCAL m.lcXMLRecive,m.lcUnico
lcMessage=' '
m.lcXMLRecive=lcXML
m.lcUnico=' '
TRY
SELECT 0
USE vr_packings_boxes
=CURSORSETPROP("Buffering", 5, "vr_packings_boxes&quot
XMLTOCURSOR(lcXMLRecive,"c_box",0)
SELECT c_box
DO CASE
CASE EMPTY(NVL(qty,' '))
THROW Quantity is empty '
CASE EMPTY(NVL(box_uq,' '))
THROW 'Boxtype is Empty '
CASE EMPTY(NVL(packing_uq,' '))
THROW 'Packing Numeber is empty '
ENDCASE
SELECT vr_packings_boxes
APPEND FROM DBF('c_box')
REPLACE vr_packings_boxes.boxdate WITH DATETIME()
REPLACE vr_packings_boxes.TIMESTAMP WITH DATETIME()
BEGIN TRANSACTION
IF NOT TABLEUPDATE(.T.)
IF laError[1]=1526
THROW laError[3]
ELSE
THROW laError[2]
ENDIF
ENDIF
END TRANSACTION
lcMessage='Caja ingresada correctamente'

CATCH TO loException
IF TXNLEVEL() > 0
ROLLBACK
ENDIF
IF loException.ErrorNo=2071
lcMessage='Error:'+' '+loException.UserValue
ELSE
lcMessage='Error:'+' '+loException.MESSAGE
ENDIF
FINALLY
USE IN SELECT ('vr_packings_boxes')
USE IN SELECT ('c_box')
ENDTRY
RETURN lcMessage
ENDFUNC


As you can see is very easy the problem is the XML size
I test with 1000 records and it`s very fast but with 5000 or more (depends of the number of columns)consume a considerable time. So if you planning to use this aproache, is very easy to implement, but you must be very careful in the size of the cursors, the remote views help very much when you need to limit the scope of the result, and you can use the remote views with FOX Native or with SQL Server, or Sysbase or whatever you want, and the best thing is the UI, you can use Visual Fox Fat Clients, or .net winforms or webforms.

 

[bernardmanning]

Thanks CaMig1

Thanks for posting the example code here, I'm familiar with local and remote views as they are our data retrieval mechanism at the moment.

I plan to replace the views with the cursor adaptors and then convert the output to XML. I guess it doesn't matter how the data is retrieved, cursor adaptors, views or direct table access as long as it's in a cursor I can 'XML' it.

I guess coming from an application where we use views but still return large record sets then I'd have to see how performance is.

Have you had to change the way your interfaces are constructed in order to accommodate the 'limited' record set size?

Thanks, Bernard.