469,626 Members | 1,447 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,626 developers. It's quick & easy.

Sqlhelper or not Sqlhelper that is the question.

Hello All,

What is the consensus on using sqlhelper or not using sqlhelper when calling
stored procedures?

We're trying to go with a standard for our projects and personally I prefer
not using sqlhelper, but some here do. I'm just curious if there are any
good arguments for or against it...

Thanks,
John
Oct 6 '06 #1
4 1996
What version of the framework are you using. If you're using SqlHelper I'm
assuing you're using the 1.0 or 1.1 framework correct?

The decision on a standard for your DAL and other data access truly depends
on how you want to design your business objects or data container objects
that your filling with the data from the stored procedure. SqlHelper is great
if you want a fast way to implement ADO.NET to fill custom class instances,
however if you want to use strongly typed datasets from XSD, SqlHelper is not
the best or most flexible way to fill and manage those datasets when it comes
to persistence and referential integrity.

If you're simply executing a stored procedure on the fly with no concern on
retriving data for business logic or do not have a business layer (and are
not using complex forms of databinding), then by all means SqlHelper is a
pretty quick way to get the job done with little overhead.

"John F" wrote:
Hello All,

What is the consensus on using sqlhelper or not using sqlhelper when calling
stored procedures?

We're trying to go with a standard for our projects and personally I prefer
not using sqlhelper, but some here do. I'm just curious if there are any
good arguments for or against it...

Thanks,
John
Oct 6 '06 #2
We're using version 2.0. Thanks for your input Chad.
"Chad Scharf" wrote:
What version of the framework are you using. If you're using SqlHelper I'm
assuing you're using the 1.0 or 1.1 framework correct?

The decision on a standard for your DAL and other data access truly depends
on how you want to design your business objects or data container objects
that your filling with the data from the stored procedure. SqlHelper is great
if you want a fast way to implement ADO.NET to fill custom class instances,
however if you want to use strongly typed datasets from XSD, SqlHelper is not
the best or most flexible way to fill and manage those datasets when it comes
to persistence and referential integrity.

If you're simply executing a stored procedure on the fly with no concern on
retriving data for business logic or do not have a business layer (and are
not using complex forms of databinding), then by all means SqlHelper is a
pretty quick way to get the job done with little overhead.

"John F" wrote:
Hello All,

What is the consensus on using sqlhelper or not using sqlhelper when calling
stored procedures?

We're trying to go with a standard for our projects and personally I prefer
not using sqlhelper, but some here do. I'm just curious if there are any
good arguments for or against it...

Thanks,
John
Oct 6 '06 #3
At my shop, we use the SqlHelper v2.0 (not the Ent Lib provider model one)
for almost everything. Its very compact code, and everybody is familiar with
it. In our case, it's very unlikely we'll ever use anything but SQL Server,
and it works fine with SQL 2005 as well. Plus, we like the idea that you can
make a stored proc call passing an object array of parameter values all in a
single line of code, and have your SqlParameters automatically cached by the
static SqlParameterCache class in it.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"John F" wrote:
Hello All,

What is the consensus on using sqlhelper or not using sqlhelper when calling
stored procedures?

We're trying to go with a standard for our projects and personally I prefer
not using sqlhelper, but some here do. I'm just curious if there are any
good arguments for or against it...

Thanks,
John
Oct 6 '06 #4
Thanks Peter!
--
John F
"Peter Bromberg [C# MVP]" wrote:
At my shop, we use the SqlHelper v2.0 (not the Ent Lib provider model one)
for almost everything. Its very compact code, and everybody is familiar with
it. In our case, it's very unlikely we'll ever use anything but SQL Server,
and it works fine with SQL 2005 as well. Plus, we like the idea that you can
make a stored proc call passing an object array of parameter values all in a
single line of code, and have your SqlParameters automatically cached by the
static SqlParameterCache class in it.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"John F" wrote:
Hello All,

What is the consensus on using sqlhelper or not using sqlhelper when calling
stored procedures?

We're trying to go with a standard for our projects and personally I prefer
not using sqlhelper, but some here do. I'm just curious if there are any
good arguments for or against it...

Thanks,
John
Oct 6 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Rajesh Madhra | last post: by
reply views Thread by Rajesh Kumar | last post: by
reply views Thread by Rajesh Madhra | last post: by
7 posts views Thread by Neven Klofutar | last post: by
reply views Thread by rockdale | last post: by
reply views Thread by Tim::.. | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.