Auto generating DAL in an ASP.NET application

Given a stored procedure, is there a way 开发者_Go百科to auto generate a Data access layer? I understand that this can be done using Codesmith by creating cs templates, but was wondering if there's a free/paid solution out there.

The plan is for the architecture to have:

ASP.NET code behind -> Business Layer -> Data Access layer -> Stored Procedure.

The BL layer acts as a pass through to the DAL and can be auto generated as well.

Any tips/advice is really appreciated!

---

Just use Entity Framework:
http://msdn.microsoft.com/en-us/library/bb399203.aspx

---

Entity Framework in its current form is a non-starter for stored procedures. There's simply too much manual work that has to be done to get each stored procedure to work. I can't speak for .net 4 Entity Framework, though.

LINQ to SQL is very stored-proc friendly. Run SQLMETAL with the /procs option to have it autogenerate your DAL.

Two constraints, though:

1. LINQ to SQL will not run stored procs that use dynamic SQL.
2. LINQ to SQL also will not run stored procs that return data from temporary tables.

The obvious first reason is that LINQ to SQL can't generate the necessary metadata for these sprocs, but dynamic SQL in stored procs is bad practice anyway.

---

I don't yet suggest that you use Entity Framework as it still has a lot of quirks. When .NET 4.0 is officially released you will then have Entity Framework 4.0. With that release I will probably abandon NHibernate and LINQ to SQL (both have very different roles) and just use EF as it has both the ease of use of LINQ to SQL and the flexibility of NH.

For now I suggest that you use LINQ to SQL as it is very easy to get up and running and most of the time it just works!

---

Linq2SQL or SubSonic both work well for this purpose.

Edit: Linq2Sql is supposedly "dead", but it's still quite useful in its current form. I just wouldn't make any long term investments in it.

---

Another vote for Entity framework, though this will depend on the underlying table structure, not a stored procedure. I am not aware of a way to allow Entity Framework to determine the class structure based on stored proc output.

I've determined that our best approach is to manually code our classes and CRUD stored procedures. Many will argue with that solution, but in my experience using any sort of ORM framework results in less-than-optimal SQL that is limited, especially considering the power of using stored procedures that the framework will block.

Cliche's are there for a reason: if you want it done right, do it yourself. The more 3rd party components you introduce into your application, the more problems you're asking to solve that aren't under your direct control. I hate to subscribe to the Not-Invented-Here syndrome, but this is one case where I believe it is valid.

---

Check this list of most famous ORM tools ".Net"