I’ve wanted to write this post for a while but have held off until I had completed my posts on dynamic data (DD) display and validation attributes and my thoughts on Linq-to-Sql.
Disclaimer: this post is all about DD on .Net 3.5 not .Net 4.0, I’ve not had a chance to play with the .Net 4 version yet.
Now DD provides an excellent way to build CRUD applications against a database, in a matter of moments you can have a functioning application and as its Asp.Net you can easily customise the application to add security, change its appearance, etc and through its Meta data driven buddy classes it becomes easy to alter what DD renders.
However, it is when you want to extend a DD application to do more than its simple CRUD operations you start to run into its limitations. If using Linq-to-sql, without extending the entities, then you are effectively forced to work in a Transaction Script style which is fine for simple applications but very quickly you start to struggle as the complexity rises, plus, it is almost impossible to do TDD with DD & Linq-to-sql combination.
If you extend the entities in Linq-to-sql or use Entity Framework then you can start to work in an Active Record style but due to the intertwined nature of the logic and the data its still almost impossible to do TDD (an interesting aside is this post I found which mentions ‘the Active Record Anti-Pattern’ which is the first time I’ve heard of one of the main architectural patterns described as an ‘anti-pattern'). By extending the entities you do gain the ability to add logic to them making some tasks easier but as the complexity continues to rise you again run into problems trying to make what should be easy work for you.
An example: In my last job the final piece of work that the team worked on we decided to use DD as it provided us the opportunity to get the site working in a short period of time. Now everything started fine we got the site working quickly, styled it appropriately and it all looked good, then the changes began. With each change the logic that was required increased in complexity and if we hadn’t been using DD we could have had a nice suite of tests to help us test the logic but we didn’t, so we could only perform functional testing which meant that the boundary and corner cases were difficult to test and mistakes were made.
What I and my previous team learnt from this is that when using DD there is a tipping point you reach where the functionality DD provides is outweighed by the complexity of extending it.
So should you use Dynamic Data? As with most things it depends – if you only need CRUD actions like a simple data entry application then its perfect, but if you know that you’ll need to extend or implement complex logic I would suggest that you use standard Asp.Net web forms or MVC as it will ultimately be quicker and easier for you to develop and test.
I’d love to hear from anybody who has experience from using DD and how they got on.
Thanks for that.
ReplyDeleteI've not done what you're talking about but I find your conclusions interesting.
Well, I work with and teach ASP.NET since Framework 1.0 and VS2002, and I'll tell you, I've never seen anything so complicated to grasp like DD. Most, if not all new ASP.NET-related technologies are easy to understand by just reading the related Microsoft Trainer Handbook and doing some labs. DD just isn't like that, and it just doesn't seem to worth the time because you can do it in other ways like MVC or some other pattern based on EF for example, that (maybe) are not so "CRUD-site-up-and-running-in-5-minutes", but leed to a solution that can easily fits into your organization's development process. It seems your point of view is the right one: if you're doing a small app with just CRUD and no business rules, with no worries on things like TDD and other methodological stuff, then DD is a valid option. Aside from that, is a nice technology to build quick samples to impress the crowd on roadshow-like events. I know that somebody will reply saying "We use it on my company and it's great". Ok, good for you. My point is that it's so intricate that most people will choose others technologies - that, after all, are not so different in productivity - where they can be productive in less time.
ReplyDelete