Re: Critique my LINQ to SQL strategy using stored procs, please
- From: "Mr. Arnold" <MR. Arnold@xxxxxxxxxx>
- Date: Tue, 24 Feb 2009 11:18:09 -0500
<dcs@xxxxxxxxx> wrote in message news:249c44ba-7668-44b8-864b-1527ab9b2c5e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
My group is about to embark on building a new ASP.Net web application.
LINQ to SQL seems like a good option for our data access needs, but
I'm not sure I'm using it correctly. I'm hoping someone can critique
my strategy before I get too deep into it.
Here's the scenario:
1. We will be using all stored procedures. No SQL will reside in
the .Net code (company policy)
2. All business logic will reside in the stored procs (company
policy)
3. We expect a total of about 500 stored procs will be created
for this app. The vast majority of these procs will be simple, one-
statement SELECT, INSERT, UPDATE, and DELETE procs.
4. The web app will have moderate use on an intranet by no more
than 10 users.
My strategy:
A. Using LINQ to SQL, create a single LINQ to SQL dbml
B. One-by-one, drag my procs into the designer. No db tables
would be added to the designer
C. Call the stored procs directly from code
D. When filling grids, formviews, etc, use: FormView1.DataSource
= myDataClass.mySelectStoredProc(23); FormView1.Bind();
E. When updating, inserting or deleting, call the proc directly,
as in: TextBox txt = (TextBox)FormView1.FindControl("User_ID");
myDataClass.myDeleteStoredProc(txt.Text);
F. All validation would be done with ASP.Net validation controls
I expect little or no custom code to be written at the data access
level. I have played with this and it appears to work very well. My
question: am I being horribly naive? Are there compelling reasons to
move beyond this simple approach given my all-stored-procs mandate?
Please critique.
Why bother with LINQ-To-SQL? The power is the use of LINQ to work with the virtual database, which using all stored procedures defeats the purpose of using LINQ-To-SQL .
You might as well go with SQL Command object, and data readers, if all that's being used is stored procedures.
.
- References:
- Prev by Date: Tools for Office question...
- Next by Date: Re: Critique my LINQ to SQL strategy using stored procs, please
- Previous by thread: Re: Critique my LINQ to SQL strategy using stored procs, please
- Next by thread: Re: Critique my LINQ to SQL strategy using stored procs, please
- Index(es):
Relevant Pages
|
