The last couple of months have been pretty busy, and the updates to this site have suffered as a result of that. When I'm not working I'm in the middle of migrating all of my personal data (including this site) off Domino. I've got most of the work done towards migrating over to SubText, but I'm having trouble finalising a site design. The fact that I'm pretty average when it comes to designing layouts is a bit of a hindrance. I'm finding SubText pretty nice to work with from a skinning perspective - however I'm pretty easily sold - whenever you can develop a skin using mostly Notepad then I'm happy. For some reason it just seems to be a lot cleaner and simpler than DNN skins were when I tried them. I'm about 90% complete doing my skin for this site, at which point I can run the migration and shut down my Domino server.. forever.
On a work note, I've recently been working on a project which had some pretty tight timelines. The actual application required was pretty simple (about 2-3 weeks of work maybe), but the timeline was pretty tight. Developing it has been an interesting exercise in terms of rapid development, because the tight timelines and small scope of work allows you to really easily see where your time estimates were accurate vs where they were way off the mark. It got me to thinking (again) about developing some simple templates and libraries of reusable code, to try and speed up certain things without going overboard and developing a full on framework. I sort of started something like this a while back, but questioned it's value, so I stopped. Now I'm thinking about ways of revising the approach based on lessons learned.
I used LLBLGenPro for this project, and the amount of time it saved was quite incredible. I've used LLBLGenPro before, but it really came into it's own here - not having to write a single stored procedure really did speed things up, as well as enabling the development process to be incredibly agile. Obviously LLBLGenPro isn't going to be suited for every project, but it really is a great tool that's incredibly easy and powerful to work with.
One of the areas I found took up an overly large amount of time was messing about with GridViews. GridViews are one of those things I've not used a large amount of. Previous projects I've worked on have used DataGrids, but have used them in a way which was less than ideal. Those implementations always felt like they were too manual, and there was too much messy work going on in the codebehind. This was compounded by the fact that due to the nature of a lot of what was going on there (accessing drop down list controls, using FindControl on rows, etc), it couldn't really be seperated out into the Business Logic layer. Less than ideal. The way to reduce the manual nature of these things seemed to lie partly with the various GridView DataSource controls, however the SqlDataSource always felt like it was breaking good 3 tier architecture, and the ObjectDataSource looked from a distance like it needed a bit too much work to get it going (I don't think this needs to be the case, but I've seen a few implementations of it, and they all vary a lot - in size, features, and complexity). Enter the LLBLObjectDataSource. I didn't even know this existed, so I was quite amused and pleased to discover it. So far it looks like it does the business, and does it well. I was able to throw together a Grid with all the functionality I needed without needing to write much code at all - best of all, the Data Access components require absolutely no use of FindControl or the need to bind primary key ids to CommandArguments (not that the latter is bad, it's just not needed). The result is a much tidier code behind file, and a load of data functionality without much work at all - it also has built in support for paging (server side) and sorting, again without the need to write a single line of code. Unless of course you want to change the functionality, in which case, go ahead. All in all it's a neat thing to have in the Developers toolbox to cut down the amount of time you spend working with Gridviews.
Taking it one step further, I'm keen to check out the Web Client Software Factory at some point. I browsed through a quick article in MSDN Magazine which covered the way it handled removing as much code as possible from the codebehind file, and it looked like it did a good job of it. After experiencing the Web Services Software Factory I know in advance that I'd definately not want to use their data layer generation code, however if it'll let me use their UI/BL seperation and combine it with LLBLGenPro's Data Access then I'll be happy indeed.
Technorati tags: Ross Hawkins