Database applications best practices in .Net

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 Lin开发者_如何学Goq2SQL, 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?

Entity Framework and NHibernate are both what are called Object / Relational Mappers. They both generate a layer that bridges the gap between objects and databases (sometimes called Object Relational Impedance Mismatch).

I cannot recommend using an OR/M enough. Either one is good; NHibernate has a bit of an edge in security, but it does seem to have a steeper learning curve. I personally use Entity Framework, but it truly is just a matter of preference.

Both of the frameworks have a provision for when you just can't get done what you need to get done with the tool, and you can call back in and execute a stored procedure directly, so you're safe in that regard.

LINQ2SQL is a more database oriented technology, but it qualifies as an OR/M. I would skip straight to EF. EF was part of .Net 3.5 SP1, found here.

Here's an example of some code to retrieve a customer from a database using EF:

using (var ctx = new DBEntities())
{
     var employee = (from e in ctx.Employees
            where e.User.UserName == userName
            select e).FirstOrDefault();
}

Another reason to use an OR/M, in my opinion, is that they tend to promote a design view of your code to be a first class artifact. What I mean by this is that you end up with a nice graphical view of the relationships between your entities (because the editor is drag and drop) that you won't abandon when you end up short on time.

Here's MS's link on getting started: http://msdn.microsoft.com/en-us/library/bb386876.aspx.

HTH.

Try LLBLGen: http://www.llblgen.com/defaultgeneric.aspx

They have a simple UI that allows you to point to your DB and instantly have all of your DAL generated for you in minutes. Setup and integration was far easier than any of the other ORM products I saw. It is customizable as well, but I still haven't done much with customization yet. Need to find out more info there myself.

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.