> I believe I'm OK security wise as the string is created in a
> data translation layer that converts a persistable object to
> a Sql string.

:-)

I just always consider that since I was last burnt by it <g>

> The Sql string represents a parameterized call to a stored
> procedure and is passed to a Sql command object.
>
> The big drawback to this approach is no access to output parameters.

Why not?
set the parameters direction to ParameterDirection.ReturnValue for returns
or ParameterDirection.Output for OUTPUT params

> There are a few advantages, however:
> 1)It is easy to debug as I can cut and paste the resultant
> string into query analyzer.

True, but SP's are developed in QA, and can be run (if you take out the
CREATE PROC at that top, and manually declare and set params, etc <g>


> 2)There is much less dependency on the data access
> technology. It was relatively trivial to convert my ADO code
> to ADO.NET.

True

> 3)My data access layer can be very simple.

I don't understand why it would be any easier than a layer that passes the
call through to the DB?


> All calls to the data access layer from the data translation
> layer look like this:
>    return SqlService.ExecutePersist(sqlString,logon);
> All data retrievals look like this:
>    return SqlService.Fetch(sqlString,tableName,logon);

Ahh..that's why :-)
The problem IMHO is type safety, etc
Having a more detailed data layer with typed params, will result in more
robust code IMHO


> I suppose it is a whole other topic, but I decided to use a
> limited subset of the functionality available in ADO.NET. For
> example, I unpack datasets into collections of objects,
> rather than have the client app interact directly with the dataset.
>
> thanks, Greg

FWIW I've tried :
        custom objects returned from the DAL
        datasets returned from the DAL
        strongly typed datasets returned from the DAL

the custom objects *are* smaller than datasets for transmission up the
layers, and I prefer them, but they are more work, so sometimes I resort to
the others (depending on projects costs,timescales, etc)

Anyawy..I'm off home
Have a good bank holiday w/e :-)
Merak

You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to