7

I am developing a complex business application wherein there will be a data access layer. As of now we have two options - either to create our own custom data access layer or to use a Microsoft inbuilt library. I am looking for some basic reasons to go with either option.

Any reply will be highly appreciated.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Mukesh Kumar
  • 166
  • 2
  • 5
  • 13

3 Answers3

5

Another option to consider is Entity Framework 4 as it gives you a full ORM. Plus with the latest CTP 5 of code first with Entity Framework is looking very promising.

With that being said Enterprise Library 5 does make data access almost trivial as long as you have a convention that your SQL table columns match your object properties with ExecuteSprocAccessor and ExecuteSqlStringAccesor. If you use these two extensions methods you can get away from dealing with IDataRecord, IDataReader and the usual command objects and your data access ends up looking like this:

var books = DataBase.ExecuteSqlStringAccessor("SELECT [Id], [Name], [ISBN] FROM Books", rowMapper).ToList();

Some Pros

  1. Enterprise Library does offer a robust framework which includes Unity (IoC), logging, validation, exception handling, and policy injection to name a few.
  2. Lots of documentation and quick starts for the various application blocks.
  3. Extensible and configurable to do almost anything.
  4. In Ent Lib5 a fluent configuration builder was introduced to relieve some stress from the mountains of configuration sections.

Some Cons

  1. Very large framework, you might find yourself needing to reference 2+ assemblies to get one thing to function properly.

  2. Potential configuration nightmare, however the use of fluent configuration builder and updated application block config editor does reduce some of the pain.

In the end I use Enterprise Library as it helps me build applications faster and I don't have to reinvent the wheel. The best bet is to try each one out, ADO.NET, EF4, Ent Lib5, or the many other options and just see which one feels right for your needs.

Randy Levy
  • 22,566
  • 4
  • 68
  • 94
Mark Coleman
  • 40,542
  • 9
  • 81
  • 101
  • @Mark: "you might find yourself needing to reference 2-3 assemblies". For using the Validation Application Block allone you need 6 assemblies. – Steven Mar 01 '11 at 16:37
  • Adjusted answer to be 2+, That is my biggest gripe with EntLib, lots of assemblies to reference to get things to work. – Mark Coleman Mar 01 '11 at 16:43
  • 1
    In DAAB, object properties don't have to match the SQL table column names. You can use a MapBuilder to define a custom mapping. See examples: http://entlib.codeplex.com/discussions/212712 and http://entlib.codeplex.com/discussions/218660 – Grigori Melnik Mar 01 '11 at 17:40
  • Thanks for the info, I was aware of the MapBuilder, just didn't want the answer to be to much on how to use EntLib. Just wanted to show it didn't have to be hard to use. – Mark Coleman Mar 01 '11 at 17:42
  • Additionally, see Exercise 4 in the Data Access Hands-on Lab: http://go.microsoft.com/fwlink/?LinkId=188936 – Grigori Melnik Mar 01 '11 at 17:48
  • 2
    Re: # of assemblies. Are 4 assemblies (Common, Data, ServiceLocator and Unity) really that many? – Grigori Melnik Mar 01 '11 at 17:53
2

I would certainly not recommend Enterprise Library. As the name implies, most of the sub-projects are very "enterprisey", which implies that they are mostly over-engineered and require lots of XML configuration. Unless you find that appealing there are much better offerings available.

Having some past experience with rolling my own ORM as well as using a host of different frameworks, I have now mostly settled on using EF4 (Entity Framework) as it is built-in and therefore readily available even in shops that are wary of open source or even commercial 3rd party components.

If you are working with an existing database, EF provides a way to generate a starting entity model from that database, which you can subsequently modify and synchronize in a visual designer. If you do not have a database, or if you dislike designers and prefer working with code, Microsoft has made available a CTP download that enables working with EF in a "code-first" manner, where the database mappings are expressed in code. You can subsequently generate the database using the defined classes.

If you're open to using open source, NHibernate is an excellent and mature option, with good 3rd party support (visual mapping designers, profilers, etc.).

I almost forgot to mention that under no circumstances should you roll your own database access framework. Spend your time writing the WHAT of your application and not the HOW, given the abundance of options available for this particular functionality.

Morten Mertner
  • 9,414
  • 4
  • 39
  • 56
1

If you are after an ORM (Object Relational Mapper) have a look at Habanero. This is an open source project that will allow you to build a full domain or reverse engineer the domain from your database. It has a bit of a learning curve, but has good support and a number of additional tools to support it. FireStarter Modeller is one such tool that gives you a windows interface for building your domain objects or reverse engineering them from a database.

You can download the latest version from SourceForge. For more info you can register at HabaneroLabs and/or check out the habanero wiki.

Andrew
  • 5,215
  • 1
  • 23
  • 42