Home/ Questions/Q 3878782
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T22:39:05+00:00

Back in 2003 I started making web applications that used databases in PHP. Of

  • 0

Back in 2003 I started making web applications that used databases in PHP. Of course, I started off just putting SQL queries directly in my code, not using stored procedures, prepared statements or any kind of ORM framework. But back then it was a common practice, as is evidenced by the code I’m working on today (a VB.Net web application built around that time).

The application uses about a dozen stored procedures, some prepared statements and lots of SQL queries directly in the code. Generally, there are redundant blocks of code that get the connection, run the SQL query (a string), then use a reader to extract data using hardcoded field names. It’s 2011 now, writing this kind of code was easy and therefore popular in 2003 but I’m guessing it’s not the best practice. It’s not secure or easy to maintain, and I haven’t touched the stored procedures.

I want to move beyond hardcoding sql queries in applications and manually parsing data from responses. What are the current best practices and tools for creating database applications in .Net? I’ve heard of Linq2SQL, Entity Framework, NHibernate and some other technologies, but I don’t know when they should be used or if they are still current.

I’m using Visual Studio 2010, VB/C# and SQL Server 2008 Express

Edit: It looks like most of you are discussing ORM software. This sounds like what I want; we have several tables with a lot of information that could be accessed as an object. When should I instead use a standard query or prepared statement?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your hunch to use object relational mapping (ORM) technologies is a good one; there are frameworks (as you’ve mentioned) which have support behind them which make interacting with data in a dynamic way (say, without stored procedures, query generation on the fly) and a non-dynamic way (stored procs, etc) easy.

    You covered the current landscape of ORM technologies, here is a breakdown of some of the differences of each.

    NHibernate

    An open source project which is based off the Java Hibernate project. It is very active, and has great support for a number of scenarios.

    LINQ to SQL

    While not officially dead, it’s been publically stated that the focus for development will not be in LINQ-to-SQL. That effort is going to be directed at LINQ-to-Entities. While it’s generally a better idea to work with LINQ to Entities (if choosing between this and that), there are issues; model generation is not as clean as some would like, the metadata mapping model that they use doesn’t allow you to use models from different designers easily, and other issues that NHibernate has probably overcome a long time ago.

    LINQ to Entities

    Currently the preferred method of data access in .NET (as evidienced by not only designer support and integration in VS.NET, but in frameworks such as RIA), this is what MS is going to devote energy into when dealing with the ORM space. It’s currently in its second major iteration (the first being found difficult to use by a number of people), the ease-of-use has definitely increased.

    I’d also look for future integrations with other MS technologies.

    Regardless, all three technologies will allow you to expose your stored procedures in a way that will return object models to you instead of data sets that you have parse/use string lookups for.

    They will also handle the case where you have to round trip the data back into the database; they just each go about it in different ways.

    • 0