A new way of writing?

My friend Dan is in the process of trying to get a MbUnit/Gallio book off the ground as a self-published work (well sort of, you see the full details if you have a look at Dan’s blog post).  If you know anything about unit testing or what to learn that go and have a look.  The more people involved the better the output will be.

Dan’s idea got me thinking about an idea that I’d had a little while ago.  If you’ve followed this blog for any length of time (I’m sure I have more than one reader out there) you’ll see that I was in the process of updating my Beginning ASP.NET 2.0 Databases book to .NET 3.5 but aborted it due to time constraints.

However I’m now thinking that it’s something maybe worth doing a self-published, peer-reviewed, peer-written (?), book that covers data access in the .NET world.

It’s a big chunk of work, especially if you consider all the things added since .NET 2.0.  Think Data Annotations, Data Services, LINQ to Entities, SQL Azure, etc. then it’s an awful lot of work.

And would you limit it to the ASP.NET world?  As well as the desktop development (WinForms and WPF) we also have ASP.NET MVC (alongside the traditional WebForms), Silverlight (where you’re adding in bits of WCF for Data Contracts), and Azure.

And would you add unit testing best practices into the mix (perhaps tying back into the MbUnit/Gallio book)?  And also best practices for nTier development (which is a requirement if you add Silverlight into the mix)?  And what about telling the world not to write data access code in UI code and put it in a Data Tier?

It very quickly gets very complicated.

So I’m thinking that we have several paths to work down.

• We have the “basics” which would cover (perhaps in a Console application so that we’re not polluting what we’re talking about with platform specific ideas) things like the DataReader, DataSet, and LINQ to Entities.
• Once the basics are out of the way we add in details about nTier and separation of UI –> Business –> Data tiers.  For basic applications it may be overkill but to my thinking it’s the way that we need to go.  Even if it’s just a separation into UI –> Data then it needs to be considered and "forced”.  Well, forced is probably too strong a word but you get the idea.
• Testing then needs to be covered – which is now a lot easier as we have the separation of concerns so we can test the Data tier separately and not having it horribly integrated into the UI code.
• Then the WCF bits and how we can use this to get across server separation if needed (now that we’ve a nice nTier model!).
• Then we get to the parts where we talk about specific UI models: WebForms, WinForms, MVC, WPF, Silverlight.  And all the lovely control goodness that we have in there.

In my rough outline there are lots of things missing – Validation (DataAnnotations, etc.), Data Services, SQL Azure – and some things that are not quite defined.  And if feels a little too “forced” (there’s that word again) by pushing an nTier model for all development (although by doing this we allow any data access method to be used in the Data tier without affecting the way that we handle the Business and UI tiers).

That’s just my initial thoughts (so that I can get them down somewhere rather than percolating in my head where nothing will ever happen with them).

And don’t even get me started on what databases we need to consider (SQL Server for definite, but what about MySql and Oracle?).  And would you need to consider other data forms such as XML, RSS feeds, etc.

As I’ve wrote more, it’s getting more complex :-(