Pixata Custom Controls
For Lightswitch

Recent Posts

Popular tags (# posts in brackets)

Anonymous types (3) ASP.NET (5) C# (3) C# tricks and tips (2) Computers (6) Design patterns (3) DomainDataSource (3) Dynamic data (4) Entity framework (3) Entity model framework (5) F# (3) LightSwitch (12) Linq (6) Microsoft (2) MVP (2) MVVM (2) Project Euler (2) RIA services (5) Silverlight (2) SQL Server (4) Unit testing (4) Visual Studio (7) WCF (3) WPF (3)

Gratuitous link to StackExchange




The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Actually, as I'm self-employed, I guess that means that any views I expressed here aren't my own. That's confusing!


Theme modified from one by Tom Watts
C#/F# code styling by Manoli (for posts pre-2016) and Google code prettify (for post from Jan 2016 and beyond)

My rambling thoughts on exploring the .NET framework and related technologies

Please note that this blog has ben retired. Most of the material has been migrated to my new blog at www.pixata.co.uk. Please update your bookmarks to point to the new blog.

Well, having posted about my excitement over discovering ASP.NET Dynamic Data (ADD), I spent the last couple of weeks digging deep into it, and have eventually come to the conclusion that it was a great idea, but ultimately of little use. I mentioned a few misgivings in that previous post, and I've added a few more to the list. All in all, I don't see me using this technology much.

Having spent so much time on it, I had about ten blog posts in my head, explaining what I'd learnt, but I guess they stay in the recesses of my mind until they fade away into synaptic relapse.

The main problem with it is simply the lack of documentation. MSDN does have a section on it, but like most MSDN stuff, it's fine for reference, but little use for learning. You need to know what you're looking for, which is no use when you want to find out! There is a forum on www.asp.net, but there are significantly more questions than answers, and apparently only two people there who know anything about it. As they are quite busy, they don't have time to answer all the questions. This leaves you rather like the blind man in the dark cellar, looking for the black cat that isn't there! How long can you justify spending searching fro answers to basic questions?

Once you've found your way around, it's time to start customising the basic site that ADD creates for you. Here's where the fun really starts! One of the clever things about ADD is that you can customise pretty much everything. One of the drawbacks is that if it's going to be useful, you have to customise pretty much everything. By the time you've finished writing custom filters, custom field templates and so on, you might as well have written the whole thing from scratch yourself. Sure, if you have a big database, as in with a large number of tables, and you want to get something up quickly that people can use, then ADD is great. However you can't hand this over to end users. There's too much you need to do to it first.

Customising isn't as easy as the (few and out of date) videos make out either. A lot of the time things just don't work the way they are supposed to. Visual Studio 2010 seems to be to blame quite a lot here, as one of the main source of weird errors was the mismatched namespace references that appeared when I created or copied templates. The whole customisation process needs a lot of attention.

However, there is a more fundamental problem with ADD in my humble opinion. Microsoft certainly hit the nail on the head when they recognised that ASP.NET developers spend far too much time writing data access pages. ADD gives you a full CRUD site in seconds, which is what got me excited in the first place. The problem is that it does this at the expense of the user. Due to the fact that the ADD stuff is all templates, everything has to be deduced at run time. Database table schemas are examined when the page loads, and this takes time. The end result is that ADD sites are slow, certainly slow enough to annoy the users. The truth is, how often does the structure of a database change once it's built? You don't need to have it dynamically generated every time. Generate it once, and then leave it alone unless you tell it explicitly that the database has changed. Which brings me to a suggestion...

I doubt anyone from Microsoft will ever read this humble blog, but if they were to, I would like something that I feel would be a great balance between the ease of creating an ADD site and the speed of non-reflective code. Given that the technology already exists to create CRUD pages from a database schema, why not create fixed CRUD pages from the schema, instead of blank templates that don't even know what table they are going to use? That way you would have the speed of creation for the site (it would take the same time as creating an ADD site), but as the pages would not need to access the schema and work out what to do with the table, the whole experience would be a lot faster for the user.

I guess what I'm suggesting is a sort of code-generation tool that creates the CRUD pages for you. As far as I can see, Microsoft have pretty much all of this there already, and it would be a much better option overall.

Having spent some more time integrating RIA services and the DomainDataSource control, I'm more convinced that this is the best approach today. You get the benefits of a layered application, with very little code. The end result is a whole lot faster than trying to customise ADD pages, and they run a lot faster than ADD.

Thanks for the try Microsoft, it was a great idea. Maybe it will be the springboard for something that actually works.

Comments are closed.