Invoking Stored Procedures through a One Line Native .NET Method Call

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Mark Frishman » Invoking Stored Procedures through a One Line...

17 posts, Page 1 of 2

1 2 »»

Invoking Stored Procedures through a One Line Native .NET Method Call

Rate Topic

Display Mode

Topic Options

Author

Message

Mark Frishman

Posted Sunday, November 09, 2008 3:31 AM

Forum Newbie

Group: General Forum Members
Last Login: Thursday, January 14, 2010 1:42 PM
Points: 2, Visits: 18

Comments posted to this topic are about the item Invoking Stored Procedures through a One Line Native .NET Method Call

Post #599534

Anipaul

Posted Wednesday, November 12, 2008 3:08 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 1:35 AM
Points: 4,787, Visits: 1,336

Thanks Mark. This will be helpful to me. :)

Post #601214

webooth

Posted Wednesday, November 12, 2008 8:00 AM

SSC Journeyman

Group: General Forum Members
Last Login: Monday, April 29, 2013 11:08 AM
Points: 80, Visits: 579

Advertising by any other name......

Post #601405

Paul DB

Posted Wednesday, November 12, 2008 8:14 AM

Valued Member

Group: General Forum Members
Last Login: Tuesday, May 14, 2013 12:07 PM
Points: 60, Visits: 257

I cannot find any independent editorial reviews. Is this product too new (think, untested) to have been reviewed yet? Or perhaps it is too unimportant to be reviewed?

Paul DB

Post #601427

Josep

Posted Wednesday, November 12, 2008 11:24 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, May 08, 2013 1:35 AM
Points: 139, Visits: 4,605

Nice Ad. You should have included the price and licence in the article.

Anyway, I think that if you just use stored procedures, it can be a good idea, but if you've queries too then I'd have it all in the same 'place' (Entity Framework, NHibernate, etc...).

Post #601584

David Christal

Posted Wednesday, November 12, 2008 11:26 AM

Forum Newbie

Group: General Forum Members
Last Login: Friday, February 22, 2013 6:43 AM
Points: 4, Visits: 62

Brilliant.

Post #601586

englea

Posted Thursday, November 13, 2008 8:26 AM

Forum Newbie

Group: General Forum Members
Last Login: Wednesday, October 13, 2010 12:36 PM
Points: 1, Visits: 7

I've never seen a C# class file look like the one you have with an @ in front of every field and the class name.

Hrm.

Yeah. Nice ad. Prefer SMO.

Post #602173

tymberwyld

Posted Thursday, November 13, 2008 5:24 PM

SSC Veteran

Group: General Forum Members
Last Login: Saturday, February 02, 2013 8:21 AM
Points: 283, Visits: 268

First off, good job. I am starting to see this a lot, my company does something similar where they just make strongly-typed Stored Procedure classes. I've actually had a framework for DataAccess for many years that requires no custom code or code generators and supports ORM. This has helped me over the years get things up and running with data access with only 1 AppSetting and very easy calling code.

For example:

Dictionary<string, object> parameters = new Dictionary<string, object>();
parameters.Add("@OrderID", orderId);
DataTable dtData = DataService.Fill ("dbo.usp_MyStoredProc", CommandType.StoredProcedure, parameters);

If I just want to execute the Proc without any returns, it's just as easy:

int hResult = DataService.ExecuteNonQuery("dbo.usp_MyStoredProc", CommandType.StoredProcedure, parameters);
System.Diagnostics.Debug.WriteLine("Rows Affected: " + hResult.ToString());

I've seen these strongly-typed stored-proc classes being generated now in some peoples frameworks and to me, it's still too complicated. I have no extra code to maintain, the DAL does it all. It takes care of building the Procs on the fly (caching them for a relative period of time that can be configured) so that subsequent calls to the same proc are as fast as possible. I've thought about posting the code for some time, I just wanted to get support in there for the IQueryable interface for LINQ so that it could run LINQ queries as well.

Oh, by the way, it also supports Data-Paging out of the box and optimizes any ad-hoc sql you write. It does not let any "Select *" statements come across the wire and also helps you parametrize all ad-hoc sql statements if you choose to use them (and you will, once you start data paging).

That's my 2cents...

Post #602457

phrankbooth

Posted Friday, November 14, 2008 11:02 AM

Grasshopper

Group: General Forum Members
Last Login: Thursday, May 16, 2013 2:16 PM
Points: 24, Visits: 159

Am I missing something or does LINQ do this but better?

Post #602956

tymberwyld

Posted Friday, November 14, 2008 12:44 PM

SSC Veteran

Group: General Forum Members
Last Login: Saturday, February 02, 2013 8:21 AM
Points: 283, Visits: 268

LINQ does do this. There are 3 flavors of LINQ (LINQ to SQL, LINQ to Objects, and LINQ to Entities (i.e. for ADO.NET)). If you hook up SQL Profiler to a LINQ application, the queries hitting the database are horrible (except for those where you're actually calling a Stored Proc). The only thing I don't like about LINQ is all the Stored Procs are methods at the root namespace of the Objects. You MIGHT be able to change this, but each time it re-generates the code it will overwrite it. So, if you have 500+ procs like we do, there's no way to logically seperate them to make the code cleaner to call.

Post #603037

« Prev Topic | Next Topic »

17 posts, Page 1 of 2

1 2 »»

Permissions