Monday 19 September 2011

Windows 8: First Impressions

The wait is over, and by now many of you have had a chance to take Windows 8 Developer Preview for a test drive.  I haven't spent a huge amount of time with Win 8, but enough to form some initial opinions.

Start Screen and Touch

It appears Microsoft has opted to bring Touch front and center, as evidenced by the Start screen.  Unfortunately the experience is not terribly rewarding for desktop users with a traditional keyboard and mouse.  I am being kind here.  In fact, after spending a couple of hours with the Start screen I was looking for ways to turn it off.  Not because it is bad, just unnecessary.   I would liken it to running Media Center has your main shell.  Nice to look at, but in terms of productivity and value add, it brings very little to the table.  Great for tablets, but please Microsoft, make it optional for desktop users.
Desktop users are desktop users because we use a keyboard and mouse out of necessity; because we are primarily using applications like Visual Studio, Photoshop and Office.  I have no intention of running these applications on a tablet. So why impose obvious tablet-design on users who don't need them?

Metro UI

I am a big fan of Metro UI design and Win 8 has it in spades.  But again, this is central to the new shell and is of value to tablet users.  It feels like the desktop has taken a backseat, with Metro hogging the limelight.  On the desktop we see very little Metro influence, which is unfortunate, because Metro design principles could be put to good use.  For example, take a look at the newly designed Task Manager.
This design is influenced by Metro and is beautiful.  I would like to see the entire desktop adopt a similar look and feel.
Windows has been criticized for being Windows.  That rectangular boxes with content that can be minimized and resized were so 90s.  So what?  It's actually pretty workable, which is maybe why it's been with us for so long.  Could it use a facelift? Sure, but I don't see the value in discarding it as a concept.  But, with the time I've spent with Win 8 it feels like Microsoft is almost ashamed of its roots.  And that Metro represents it's commitment to it's new forward-thinking Un-Window philosophic shift.

The Eco-System
Microsoft's goal of a computing eco-system has been getting a lot of press.  I just have to ask Why?  Why an eco-system?  Why does my phone, tablet, laptop, desktop and TV have to share the same user experience?  Are the IT consumers so thick that they just can't cope with differences across these devices?  I think not.  If Windows 8 is the solution, what is the problem?  I've never felt stressed out that I use Android on my phone, Win 7 on the laptop/desktop, Media Center on the TV, and more recently WebOS on the tablet.  There are things I like and dislike about each of those.  I've never sat there and dreamt of a perfect world where all these devices work and function the same way...ahhh...think of it.

Conclusion
I understand it is early days, but my initial impressions of Win 8 were disappointing.  It feels too devoted to touch and IT consumers and less to hardcore computing (software development, databases, CGI, etc).  In its current state, I'll be looking for the "run as Win 7" hack.

Thursday 7 April 2011

MVVM Revisited

I have been working with MVVM and Prism for a couple of years now and have had some recent revelations which you may find useful.  Working with MVVM by itself, is relatively straightforward.   Combine it with other patterns, such as MVC and IoC, and things can get complicated.

Here is a common implementation of MVVM:

This example also utilises a CustomerController along with some services, all of which are supplied by the “Model”.  If you’ve worked with Prism you’ll probably recognise this rather unorthodox implementation of MVC, something I’ve never been comfortable with.  Injecting a controller into a ViewModel seems backasswards to me.  I would prefer to have the Controller be aware of the ViewModel and indirectly control/manage the Views.

Aside from being awkward, this approach does work.  But don’t expect your modules to be “modular”.  Sure, within your solution it will have the appearance of being a module, but it won’t very portable.  If you’re persistent and are dedicated, you can try to “reuse” the Customer module above, but be prepared to drag a half dozen dependent assemblies with it.

So, what is modularity without portability?  Without portability, modularity is reduced to a code organisation concept.  

Looking over this situation it occurred to me that the injection of dependencies in the ViewModel was pretty much unrestrained.  If the ViewModel needed it, just add another parameter to the constructor.  The entire Model was wide-open for consumption, provided it was registered with Unity.  Needless to say, this leads to greater and greater consumption, until finally the ViewModel is entrenched in implementation.

When viewed as a microcosm, MVVM can act like a tiered architecture.  And tiered architectures are great for scalable server applications, but pretty much ruin any hopes of portability.  

The other undesirable aspect of this is, while the ViewModel may require the ability to display a MessageBox (provided by the IMessageService), it has no use for the other 10+ methods provided by the service.  So, why not give it exactly what it needs – and no more.

One way to accomplish this through the introduction of a custom Model class:

Here the CustomerModel class defines exactly what the ViewModel demands of the Model.  In effect, it is a subset of the Model and is specific to that ViewModel.   It’s the ViewModel’s shopping list – “if you’re going to use me, this is my list of demands”.  It is now up to the implementer to provide this functionality – which is where the responsibility belongs.

With this approach the ViewModel has now been liberated and all of the “dependencies” removed.  Service methods have been replaced with delegates.  The ICustomerService can reside in the module itself, effectively making the CustomerModule a self-contained, standalone assembly.

A side benefit is that the View now contains no code-behind and is no longer dependent on the ViewModel interface.

While working through this I’ve created a new Prism sample solution, which includes a CustomerModule and an OrdersModule, Implementation project and a Shell.  I have reduced the module dependency down to a single Core assembly.  The Implementation project contains controllers, core services, a persistence manager, etc.  It knows about the modules and can orchestrate the workflow and manage the views.  The controllers “wire up” the Model and inject them into the ViewModels.   

At the moment, CustomerModule + Core is about as portable as it gets.