Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 794
  • Last Modified:

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?
0
kmoloney
Asked:
kmoloney
  • 3
  • 2
2 Solutions
 
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
 
kmoloneyAuthor Commented:
Without going thru tons of docs, how (or is) the entity framework supported in VA 2010?
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
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

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now