Best 3-tier design for non-sql backend data?

[Guest]

I'm really struggling with deciding on the best way to approach my particular
website design scenario. Most tutorials and samples assume an sql backend
database.

What I have is a proprietary database (which I'm stuck with) that I
communicate with via a dll which expects requests in xml and returns the data
back in xml.

I've initially created a generic data access class that has 2 string
parameters containing the dll method to call and a string of xml that defines
the data required from the method. The class then reads the returned xml
into a dataset and returns the appropriate table from the dataset. The asp
pages use this class in ObjectDataSource objects so that the datatables can
be bound to gridviews and can used in reports etc.

Does this seem a reasonable approach? It seems to work fine for displaying
data but I'm not sure about how to handle updating the data with this
approach. I also keep reading about strong-typed datasets. I don't see the
benefit in this scenario but I could be wrong.

I'm new to asp.net so any comments would be gratefully received.

Regards,

Bernie Beattie

 

[Sean Chambers]

I would say if your only option is to receive XML data back from your
database, then this seems reasonable.

I would like to stress though (and this is probably out of your
control) that XML is very slow to parse and should be used ONLY when
needed, i.e. a webservice or non-interopable systems data interchange.
I find it amusing that a company would opt for XML to be fed into and
return from a database system. I assume they are doing this so you can
use the database on any system. I would be very interested though to
see benchmarks of this database returns hundreds of thousands of rows.
I would imagine it slows to a crawl.

But like i said, it sounds like the dbms is out of your control, and by
using datasets you leverage the most performance possible out of these
xml data returns.

What is the name of this database software you are using? I 'm curious.

thanks

Sean