Yet another n-tier development question

[BruceG]

I'm looking to get some opinions on this. What do think is the best way to get data to the presentation layer (i.e., your VB user interface) from the business object or application layer? For example, let's say you need to load up some combo boxes from various lookup tables.

Of course bear in mind that the presentation layer must not directly access the database. The "GetRows" method seems like it would be most efficient, but I don't particularly like referring to fields by numbers and the reverse row/column structure of the array returned by GetRows can be a little confusing if I haven't had my coffee yet. What is your opinion on the use of UDTs or collections for this kind of processing?

I must admit that although I have been using VB for quite a while, I'm not a heavyweight when it comes to OO development (but I'm working on it). And yes, I have some books that I need to dig into where this is concerned. What I'm looking for here is views from folks who have been down this road before.

Thanks for your attention.

[Lethal]

I'm working on a large N-Tier application as we speak, and all of our data is structured in XML. XML is great and easy to work with. We populate our business objects using it. When our app talks with an outside datastore, we speak via web service calls. The only means of communication is through HTTP requests and sending and receiving XML.

[yrwyddfa]

We use UDT's extensively, and the performance is marvellous. UDT's are marshalled efficiently across process/machine boundaries too (they are well defined in IDL, too) Unfortunately, if you need to use ASP (and IDispatch) it will not be able to read the UDTs: using UDTs you will also be stuck with IUnknown (unless you implement all sorts of redirection classes) Depends on what you want, though.

You should avoid cross-process/machine communication (in the VB COM world) using any form of VB created object - including collections. They are not marshalled efficiently - there are exceptions such as the ADO recordset object which uses custom marshalling, but you cannot implement custom marshalling in VB. So avoid objects across any sort of boundary.

I'm sure that XML is probably the most independant way of doing things. HTML is a good wire protocol too - but you lose a little performance - the performance loss isn't linear though; XML based comms tends to be very scalable simply because of the way you have to code things. It's also very simple to convert an ADO recordset to XML (persist as XML!!) of which you can pass to the ASP response object (it supports IStream) which means no custom coding to deal with XML.

The choice is yours - I hope this helps a little

[Lethal]

Hey man, I've never converted an ADO recordset to XML before. Could you give me a small code example doing this, as well as pass it to a response object. Thanks