Linq vs MS Enterprise Library DAAB

Question

At work, we just upgraded from VS2005 to 2010. To this point, we've only used sprocs (I guess out of habit more than anything). I've been playing around with Linq (very simple tutorials - nothing major). As my first actual experience with an ORM, I like it.

In addition, I've only recently become familiar with the Enterprise Library blocks. Generally speaking, would a project use either an ORM or the DAAB, or could/would a project potentially use both? Does it depend on the situation, or just preference? Are there cases when one option is better than the other?

Thanks.

Answer 1

Hey,

One or the other... I haven't used the DAAB in a while, but LINQ to SQL or ADO.NET EF uses a designer to generate code classes that represent the database, where the DAAB is built upon ADO.NET (DataSet's and such).

I love LINQ, easy to use, you can use stored procedures just fine to get your data, or construct a LINQ query to pull the data (the code LINQ query gets converted into a database query).

So I prefer LINQ; If you use the DAAB, I'd recommend using a code-gen tool.

HTH.

Answer 2

The DAAB is closely related to the older style of database access (think DataSets) while modern ORMs like Linq are more about strongly typed entities generated from a database schema.

I'd only suggest using the DAAB if you needed database neutrality (IIRC it is well suited for use against different types of DBMS') and if you wish to avoid tools that rely heavily on compile-time magic.

ORMs are usually pretty good at delivering value in the form of ease of use and tool support. However, they often butt heads with the "object-relational impedance mismatch," where the entities look and behave like standard objects on the surface but that have far-reaching requirements on their use due to the fact that they abstract an RDBMS that is not truly compatible with object oriented computing. Your code has to "know" how to use them otherwise face pitfalls that you can't catch at compile time.

Personally, I'd avoid the DAAB. Apart from a few shining examples (Unity!) the EL is pretty heavyweight and requires a fair amount of work to understand and use properly. Its often a track-mounted jackhammer where a chisel would have worked. Most ORMs are pretty damn good, shortcomings aside. Linq to Sql is solid, and EF4 is getting there. There are also open source alternatives such as nHibernate that also provide good value for the learning curve.

If I were to start a new project tomorrow, I'd use the EF4 code-first bits that have been released recently. I think that's mainly because I'm a glutton for punishment; EF4 has been a pain in my ass...

Answer 3

We are at exactly the same point, having used DAAB from 2.0 to 4.1. FWIW this is our thinking (we really are Pro ORM):

There is a trade off between:

• productivity improvements that an ORM with code generation capabilities gives (notably by not having to hand code SProcs and Entities)
• improved flexibility that LINQ gives w.r.t. Eager and Lazy Loading, fetching just the required columns (narrowness of query allows for better hits on NC and Covering indexes etc)
• as far as we can tell, LINQ uses parameterized queries and thus performance w.r.t. plan cache and is not susceptible to SQL Injection attacks http://msdn.microsoft.com/en-us/library/bb386929.aspx

However, on the down side

• Loss of control over Entities - they are not necessarily POCO (for LINQ2SQL) and although EF4 allows for your own POCOs, this seems to be at the loss of lazy loading.
• Lack of control / determinism in the queries that could be executed against the DB, meaning that coverage testing against the DB is a potential issue (whereas it is relatively simple to identify the indexing strategy for a SPROC)
• Unless you are careful, updating of entity graphs can have unintended "depth" consequence. LINQ2SQL could really do with an "SavesWith" analogy to the eager loading "LoadsWith"

In summary, we are happy with an ORM for about 80% of our tables / entities, but would then look at custom work for the really sensitive, performance specific stuff.

HTH