Best Practice for Data Application Development - TableAdapters vs. Stored Procedures

Hello,

I am frequently asked to develop solutions using a SQL Server database and VB.NET (Visual Studio 2010).  Table adapters seem to work fine for application development on datasources when the datasource is relatively stable.  

However, when tables are constantly being modified, it seems like I'm spending as much time reconfiguring adapters, rerunning configuration Wizards, messing around with tableadaptermanagers, dataset designers, query builders, binding sources, databindings, binding navigators, and datasets.  Bluagh!  Microsoft gets an 'F' for creative naming.

So far, the only way I can see for the app to recognize a new or modified field is for me to remove a tableadapter from the Dataset designer, and then add it back in again.  But this causes problems, sometimes, with relationships between tables.

I'm by no means a "seasoned" programmer - and do so only sporadically.  But it seems to me for development of applications with volatile data schemas that it might be easier to just use straight stored procedures in SQL and call them using the System.Data.SQLClient methods, like:

        Dim cn As New SqlConnection(My.Settings.DBConnectionString)
        Dim cmd As New SqlCommand
        cmd.CommandType = CommandType.StoredProcedure
        cmd.Connection = cn
        cmd.CommandText = "DeleteARecord"

        cmd.Parameters.Add("@RowID", SqlDbType.Int)
        cmd.Parameters("@RowID").Value = intDeleteRecord

        Try
            cn.Open()
            Dim intRowsAffected As Integer = cmd.ExecuteNonQuery
            Me.ClientTableAdapter1.Fill(Me.DBDataSet.Client)

            MessageBox.Show(intRowsAffected.ToString & " Rows Deleted.", "Success")


        Catch ex As Exception
            MessageBox.Show(ex.Message)


        End Try
        cn.Dispose()
        cmd.Dispose()

Open in new window


Plus, in the end, the heavy work is on the server, and I'm guessing the applications are significantly lighter.

Any advice?
LVL 2
kmoloneyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sammySeltzerCommented:
Ever since I started developing apps, I was advised that it is better to use stored procedures for at least two good reasons.

1, when changes are needed to the sql, it is better to make the changes only one place and that is at the stored procedure level.

This help reduce not just development time but errors that could result from tinkering with several of your app pages.

2, Second reason is performance. With Stored procedures, records are cached it making it faster to call the stored procedure, rather than hit the db quite often.

So, given the choice between table adapters and stored procedures, the choice is easy for me.
0
Jacques Bourgeois (James Burger)PresidentCommented:
I agree with SammySeltzer, and personally, I do most of my database access through Stored Procedures, either handling the result in DataTable objects or my own classes.

But if you want to stick with something that is closer to .NET and simpler to use, I would explore Data Entities (Entity Framework). This is the way Microsoft has been going since around 2010. They are easier to maintain up to date that TableAdapters.

TableAdapters were developed in one of the first w versions of .NET and have not evolved much since. LINQ came after them, and the Entity Framework came after LINQ.

Although technologies such as the TableAdapters and LINQ are still supported, this is mainly for reasons of backward compatibility. The Entity Framework is all you hear nowadays at Microsoft. It appears everywhere. The first line of the documentation on the subject states it very clearly: The Entity Framework is Microsoft’s recommended data access technology for new applications.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
kmoloneyAuthor Commented:
Without going thru tons of docs, how (or is) the entity framework supported in VA 2010?
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

kmoloneyAuthor Commented:
BTW, great comments both.  :).
0
Jacques Bourgeois (James Burger)PresidentCommented:
What is VA?

If it's a typo and you meant VS, then yes, the entity framework is supported in 2010. If my memory is good (which it is not always the case after working with 11 versions of Visual Basic), data entities appeared in VS 2008 SP1.
0
kmoloneyAuthor Commented:
Thanks, and yep, it was a typo.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.