The Data Mapping Application Block

Lenny Fenster has released a preview version of the Data Mapping Application Block.  It uses the Enterprise Library, although a modified Data Access Application Block.  My understanding is that this will be rolled into the Enterprise Library sometime.  I'd heard rumors of this being worked on for quite some time, so it was no surprise.  I suppose you could think of it as the Enterprise Library's O/R Mapper -- kind of.

What do I mean by "kind of"?  There are no objects here, unless you like typed datasets, and you're required to use stored procs, which is great if it were just an option.  But if you like to use your own objects and/or want to avoid the bloat of datasets and/or enjoy the flexibility and maintainability of runtime generated dynamic sql, then you won't find what you're looking for in the Data Mapping Application Block.

Of couse, if you follow all of Microsoft's "guidance", and are already using the Enterprise Library, then this is probably exactly what you have been dreaming about.

8 Comments

  • I'm not a big EntLib fan. It's usually tries to be too much to too many.



    I'll stick with either a simple 'roll-my-own' DAL, or a decent O/R Mapper.

  • Hehe, now you're just plain getting catty about other ORMs ;) (with good cause, mind you)



  • "Of couse, if you follow all of Microsoft's 'guidance,' and are already using the Enterprise Library, then this is probably exactly what you have been dreaming about."



    That cracks me UP!

  • Heh, I like the quote that they 'propagate stored procedures for best practises'... haha, noooo not for best practises, but for the fact that otherwise they've to write a real O/R mapper core, SQL engine, meta-data management etc...

  • Paul,



    I'd be interested to hear more of you opinion on Microsoft's 'guidance'.



    I recently created a 'roll-my-own' DAL. When I explain it to other people the biggest (perceived) problem seems to be "but that's not what Microsoft says we should do!"

  • I had a look at the DAAB a while back. While I can't verbalise what I didn't like about it, I developed a severe disliking for it, and it's turned me off looking at the Entlib stuff. I wish I could verbalise it, because it's something I'd like to be able to explain to others. If you have the interest, I'm keen to see you write more about this Paul - I'd also be keen to know what you thought about the other parts of EntLib. Cheers.

  • I've come up with another critique of the DAAB. It goes like this:



    1. Lay out, on a table, 8 pages of code from a sample application using the DAAB. (The DAL code itself, the stored procs, and the hand-written business entity classes)

    2. Explain that this is the CRUD code for just one database table.

    3. Now place on the table the same functionality, implemented in my 'roll-my-own' DAL. It's less than one page long.

    4. Explain the extra features that my DAL gives, which are not in the DAAB example. (Optimistic concurrency control for starters.)



    But, since the original 8 pages come from Microsoft, I suspect some people will remain unconvinced!

  • The enterprise block just seems to be far to fat.. Written by academics. I read someweher most of these blocks started outside microsoft. The company i work at wont be using it .



    1. Loging is slow and adding your own listeners requires 3 complicated classes. Yet the default .NET loging with Levels and Providers is not even that bad and is much faster.



    2. The Caching one intrigued me for non web server hosted middle Tiers, again it is far over engineered. The Web.Cache cache for example is just as efficient (more ?) , used by 1000's of companies and has only a fraction of the code ( I decompiled it once)



    3. The Configuration block is again far too complicated. Config files and Application.Configuration is not that bad !



    4. If you want to use 1 part you have to use the rest !



    Ben

Comments have been disabled for this content.