n tier design help

[J_ B]

I'm designing some .net extensions for an existing system. The existing
system system has user configurable fields, basically most of the relevant
the data is saved in a table with text fields f1 to f40. These fields are
rendered with different names and as different types on the client by
refernceing meta data for each field from other tables.

Now if i am to make this data available via asp.net forms or a webservice or
remoting i cannot decide how to split the tiers. The business logic funtions
should be called using the field names as the user sees them not the actual
db field names (easier for 3rd parties to then use),

eg GetRecord("where name = fred") where as the actual db query would be

GetRecord("where f1 = fred")

Now should the conversion to actual db queries be done in the data access
layer or should this be done in the business logic layer first then passed
on to the data access layer?

I'm thinking of using datasets then changing column names to represent the
friendly names rather than actual db cols, good idea?

cheers

jb

[Lucas Tam]

"J_ B" <[e-mail]> wrote in news:#o**************@TK2MSFTNGP14.phx.gbl:

Now should the conversion to actual db queries be done in the data
access layer or should this be done in the business logic layer first
then passed on to the data access layer?
I think the conversion should be done on the data access layer. Your
business log layer should still use the user column names - it'll be easier
when you do your business rules.

I'm thinking of using datasets then changing column names to represent
the friendly names rather than actual db cols, good idea?

You might want to avoid datasets... especially if you're returning a lot of
rows. Datasets will gobble all available memory on your system.
--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/