Sqlhelper or not Sqlhelper that is the question.

[John F]

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

[Chad Scharf]

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

[John F]

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

[Peter Bromberg [C# MVP]]

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

[John F]

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