Re: Data Access Layer

Mike

We write our own along the lines

1/. UI Controls
2/. Object DataSource
3/. Business Object and Business Logic Layer
4/. Database Access Layer (DB2/400 or SQL Server)

We've built in the ability to Cache any object or result set returned from
the Database Access layer, which when combined with the built in Caching
support of the Object DataSource Control provides pretty good performance.
We don'yt use provider factories just simple switches to determine if the
data comes from the DB2/400 or SQL Server tables.

When I first looked into auto generating XSD's I found that support for the
nuances of DB2 SQL where not really there so felt it better to craft our
own, at least we are in control of it. Once you've got a good working model
it is fast and easy to clone it for other objects (IMHO)

Regards

Maurice O'Prey




-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx
[mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of John Taylor
Sent: 12 February 2009 23:33
To: systemidotnet@xxxxxxxxxxxx
Subject: [SystemiDotNet] Data Access Layer

Looking for recommendations on what people are using for the Data Access
Layer in their DB2/400 apps. It seems that a lot of tool and framework
vendors treat DB2 as the proverbial red-headed step-child - that is -- when
they choose to recognize its existence at all.



So what are you doing? Did you have to roll your own?