So, another small turnout last week - but good discussions none the less, with 4 of us in total (Peter, David, Gareth and Myself).

First off we had a talk about ArchAngel, the product that Gareth has architected/written, and what it solves, and around the upcoming release of the new site, as the product moves out of beta - a lot of us have given him grief over the existing DNN site, and it should be good to see it get a face lift ;o) - Following that we talked a little about the challenges of round tripping code, and the problems with a lot of the current MDA/MDG implementations, and how ArchAngel can resolve a lot of pain associated with other code generation approaches due to the holistic approach.  It's a very exciting product and hopefully at some point a screen cast or two will be made to demonstrate the various features / advantages of the product (hint hint).

I again voiced my frustrations with SharePoint - or "swearpoint" as David coined it, I think much of my problem has been around lack of good documentation, and finding the right combination of tools for doing the job i.e. not using  VseWSS projects but instead using WSPBuilder, and getting to grips with the various nuances of deployment packages and the SharePoint 12 etc. folder structure - not the mention the diabolical and misleading exceptions you get at some points - I still haven't found a good approach of TDD'ing that works across event receivers, web parts, controls etc. that doesn't introduce a large amount of uncessary complications and abstracts just to make the untestable testable - For the next SharePoint project (if I dare touch another one) I'll definitely take the time to develop a better TDD approach, and probably buy a tool like typemock to assist with it.

I brought up the  ASP.Net MVC framework - with the latest wave of information
coming after the ALT.Net conference where Scott Guthrie did a  presentation... and we discussed how it fits in with web forms, and where it leaves Monorail -based on current observations within the monorail community I believe many would consider moving across to the ASP.Net MVC platform based on what has been presented so far, though the approach and architecture is similar enough that there should be opportunities to easily shim view components etc. To work with both MVC frameworks.

After that we had some rambling discussions about Accessibility (including web browsing for the blind, designing accessible forms, x-forms, tables vs. div's for web forms and how nothing done for local/central government really conforms with their accessibility requirements, or is even tested for accessibility.

Intertwined with that conversation was the rather slow adoption of WPF (I mentioned some of the points brought up in recent panel discussion that was on .Net Rocks!), WPF & Silverlight control suites and the power of filters and binding, also include in that discussion I briefly mentioned that I'd been working on building a web based workflow designer application using the OpenJacob library (the draw2d javascript library to precise) and Monorail with some success, but would like an off-the-shelf WPF or better yet Silver light toolkit to do the same job.

Last of all we discussed Alex James's proposed question around thoughts on POCO (plain old code/c# objects) and how important it was to us (in association with ORM's / Domain Driven Design, or at least thats what we talked about).

The thoughts were basically:

• Single inheritance makes non-POCO based Orm's a pain to work with in some cases, i.e. there's a loss of control, and accommodating some scenarios such as MarshalByRef become difficult/impossible.
• Can often make it harder to enforce correct usage of your domain model, such as aggregates.
• Depending on the ORM, non-POCO objects are harder to test with in a disconnected manor.

On the flip side:

• Incorporating concepts like current/previous value can be more natural.
• Performance / ease of development for the ORM can be simplified when not accommodating POCO. You generally need to rely on proxying and virtual methods to make POCO possible, this can introduce additional complexity and
• small performance hits both on startup and at run-time (not generally that noticeable).

I also took the opportunity to once again mention PostSharp - which I've been using to prototype methods for removing a lot of the repetitive or ugly plumbing code that developers often have to write when developing non-POCO entities.

Oh, and sorry about the late write up! .. Things have been a bit crazy lately and I've been hard pushed to find the time to post this till now, I'll do better with the next chat and try and get that writen up in a more timely manor (a 1 to 2 day turn-around).

Last of all - our next chat is Thursday this week - hopefully we can push our numbers back up to 6 or 8 and catch up with some of the other regulars who haven't been able to make it over the last month and half - and as usual, if you have any topic suggestions, just drop me a comment/email etc. and I'll bring it up at the next chat.