My NDC 2009 Agenda

The Norwegian Developer Conference 2009 will take place in Oslo from June 17th to 19th. I’ve been lucky enough to get my hands on a full 3-day ticket and I’m really looking forward to this event. I attended both TechEd Barcelona in 2007 and PDC last year in LA, but I can’t help thinking that NDC 2009 has got an even more impressive speaker lineup than both of those – at least if you’re in to agile practices and software craftsmanship.

If you’re thinking pure technology NDC might not be that impressive, but I personally believe that  the quality of a conference is a lot more about the quality of the speakers and how they present their thoughts and ideas, and less about the technological content. I’d rather spend an hour reading some good articles and try out some new technology hands on, than spending an hour on a bad chair in a room that always seem to lack oxygen listening to a mediocre speaker reading out loud every word on his/her powerpoint slides.

Going to conferences is about getting inspired. It’s about getting that tickling feeling of neurons going amok and new ideas swirl around in your head. It’s about triggering activity in your anterior superior temporal gyrus. And it’s all about the speakers. Skilled speakers with a lot of experience and confidence on stage giving a talk on a topic dear and near to their heart can really make a difference. And with a speaker lineup with names like Feathers, Rahien, Hanselman, Bolognese, Miller, Haack, Dahan, Osherove, Block, Provost, Bustamente, C. Martin, Lhotka… It’s just no way that this is going to be a mediocre event. It’s destined for success!

The worst part of this conference will actually be to pick which sessions to attend. It’s just impossible to not miss a great session, but hopefully they will all be videotaped and available online shortly after the conference. But the sessions are always best live, and one got to choose something. As it looks right now I believe this will be my agenda;

 

DAY 1
Ayende Rahien	Building Multi Tenant Apps	Haven’t had a chance to see Rahien live yet, but I’ve read and used some of his works
Michael Feathers	Working Effectively with the Legacy Code: Taming the Wild Code Base	I’ve seen some videos of Feathers up on InfoQ and I highly recommend his sessions
Juval Löwy	Productive Windows Communication Foundation	Don’t know much about Löwy to be honest, but getting productive with WCF is never bad.
Rockford Lhotka	Implementing Permission-based Authorization in a Role-based World	Got to have some technical sessions to, and though I’ve never used Rocky’s CSLA framework, I’ve listen to a couple of the DotNetRocks episodes he has attended. Besides; the content suits the project I’m currently working on perfectly :)
Udi Dahan	Intentions and Interfaces - Making Patterns Complete	Yet another one of those gurus you just read and hear a lot about.
Michael Feathers	Design Sense Deep Lessons in Software Design	Feathers again; he’s just that good.

 

DAY 2
Jeremy D. Miller	Convention over Configuration applied to .NET	Been following his blog for some time and I like his involvement with the Alt.Net community. Great interview with him on the Alt.Net podcast. And besides; CoC is facinating.
Roy Osherove	Unit Testing Best Practises	Went to Osherove’s sessions at TechEd in 2007 and it was well worth it. Hope he brings his guitar :)
Ted Neward	Extend the Customization Possibilities of your .NET App with Script	Ted is a great speaker and the scripting possibilities is something I’d really like to look more into.
Robert C. Martin	Clean Code: Functions	One of the most energetic speakers out there and Clean Code will be read in the upcoming weeks.
Rafal Lukawiecki	Architectual use of Business Intelligence in Application Design	BI has always been one of those fields that were interesting, but never had the time to really dig into. And from what I’ve heard Rafal was one of the top rated speakers at TechEd 2007 (or was it 2008?).
Jimmy Nilsson	Entity Framework + Domain-Driven Design = true?	I’ve read Nilsson’s book on DDD and seen his session at Øredev last year. I’m currently working on a project were we try to follow the guidelines of DDD, and so it will be interesting to see his take on EF + DDD.
Richard Campbell Carl Franklin	.NET Rocks! Live	I’ve followed the .NET Rocks podcast for quite some time and the live recordings are never dull. Will be interesting to see who they gather at their panel this time.

 

DAY 3
Scott Bellware	Full Day Tutorial: Good Test, Better Code	I’m a strong believer in TDD and Bellware is certainly one of the gurus in this field.

As you might have noticed from my list of speakers I try to spread my sessions to cover as many different as possible. That way I know which one I can spend time with when the videos come online.

And a little tip if you’re going to NDC (or any other conference); do not hesitate to leave a session that you find boring or uninteresting. It’s your time and you’d better spend it right!

PRISM: Your guide to a well-structured UI layer in WPF/SilverLight – Part 2

In Part 1 I talked a bit about testability as one of the major drivers for why you would choose to use Prism as your guidance for a composite application. In this post I’ll try to give you some hints on how Prism address common challenges like separation of concerns, single responsibility and supporting multiple platforms.

Modularity

Modularity is what makes composite applications composite. Modularity is one of those design principles that has been around ‘forever’, and it’s just as relevant today as ever. “Modules”, “Packages”, and “Components” are all naming of the same concept; grouping related functionality together. That means that cohesion inside a module should be high; the objects within a module should work within the same context and address a common problem. If the grouping of functionality is done right then the coupling between modules should be low, because it shouldn’t be any need to reference objects that are unrelated.

The concept of modules in Prism will guide you towards the goal of high cohesion / low coupling. Modules in Prism don’t tell you how far up or down the architectural layers you should or could go, but it typically will include at least the presentation layer. Whether you choose to implement a complete, vertical slice of your application all the way down to the database, or you choose to stop right below the presentation layer is up to you. What is important to keep in mind is that a module should preferably reference neither any other modules nor the host application itself. The module must be kept as separate and isolated as possible. And because these modules are independent of its surroundings, they should be pretty easy to load into the application and by that make it possible to compose an application from these building blocks.

 

Maintainability

The biggest maintenance problems I’ve found myself in have usually been due to either large, difficult to follow code-behind files. Large classes and methods with a lot of functionality are in general hard to maintain, but my code-behind files from the pre-TDD-era had a distinct tendency of getting bloated. And not only were they big; they also had a lot of different responsibilities; from UI-logic and validation to business rules and data flow. And even data access in those early days (after all; that was what those on-stage demos and MSDN documentation thought us, right?).

Prism tackles the code-behind problem by showing you how to use UI design patterns to separate out functionality into presenter and presentation model classes. These classes do not have any graphical components related to them and so they lend themselves really nice to unit testing. The Patterns & Practices team chose to implement what Martin Fowler calls the Presentation Model pattern. The more WPF-specific implementation of this pattern is often referred to as a Model-View-ViewModel pattern coined by John Gossman, but because there’s no “official” documentation of the MVVM pattern (just a whole lot of blog posts), P&P chose to refer to the well-documented Presentation Model. But if you want to google your way to more intel on the UI pattern used in Prism, enter MVVM or Model-View-ViewModel as your search criteria. That way you’ll have a better shot at getting WPF or SilverLight related search results. A good start would be the MSDN article by Gossman, Dan Crevier’s early series on DM-V-VM, various blog posts on the MVVM-subject by Josh Smith, and Karl Shifflet’s M-V-VM articles.

 

Multi-Targeting

Should you choose WPF or SilverLight? The short and evasive answer is off course; it depends. I’m not going to elaborate on when you should choose either, but if your answer is both, then the guidance in Prism can show you how you can do this in a very smooth way. In fact; the difference between the WPF and the SilverLight version in Prism’s reference application, is 95% xaml. That is; everything but the Views are the exact same code. And by exact I literally mean the same code; instead of having the Presenter/PresentationModel-code duplicated, they actually link the SilverLight files to the corresponding WPF-files. The SilverLight projects therefore contain mostly Views, and the shared code lies in the WPF projects.

The last 5% difference implies that you can’t get all the way by changing the xaml alone; there is still some tweaking to get the WPF and SilverLight working nicely together. Since there are some subtle differences between WPF and SilverLight when it comes to functionality (SilverLight is not a pure subset, since it contains some functionality that not (yet) exists in WPF), the P&P team has used preprocessor directives on those places where they’ve had to customize specifically for the platforms.

Wrapping It Up

Building applications that are highly testable and maintainable is key for long-lived software. Splitting functionality into well-defined modules that can be developed in parallel by separate teams is key for scaling out the development process. But keep in mind that not all application will benefit from the Composite Application Guidance. Prism is not a silver bullet and it will bring more complexity into your development process. But if your needs justifies the added complexity and you know that your must ‘embrace change’ for years to come, Prism can really lay the foundation for a successful development story. And remember that Prism is guidelines, not framework.

PRISM: Your guide to a well-structured UI layer in WPF/SilverLight

I’ve had the opportunity to work with Composite Application Guidance for WPF and SilverLight (codenamed “PRISM”) for a couple of months now, and I’m really impressed with what the Patterns & Practices team has shipped this time. The forefather of Prism is in many senses the CAB framework (Composite UI Application Block) and even though I never worked with the CAB Framework myself, I’ve heard that it is a quite large and not that easy to grasp. Prism on the other hand, is quite light weight and the documentation is very concise and well written.

The feedback from CAB has also been that it’s too intrusive; it’s an all or nothing application block and it’s hard to take advantage of the UI composition patterns in existing applications. CAB is from what I have found, meant to be built upon – not with (remember, I haven’t worked with CAB myself, so if you’d like to correct me, please feel free to do so in the comments below). With Prism P&P has taken quite another approach; you’re free to use (or not use) any part of the Composite Application Library in Prism. And you can switch out whatever part that doesn’t suite your needs. For instance, a core principle in Prism is to use an IoC container to make the application highly testable and loosely coupled. And since P&P has developed an IoC container themselves, namely the Microsoft Unity, the examples and the reference application in Prism uses Unity. But if you’d rather use Windsor, StructureMap, Ninject, Autofac, or any other IoC you’re definitely free to do so.

The big difference here’s that where CAB is an application block, Prism is an application guidance. And it guides you towards building applications that are testable, maintainable, multi-targeted and modularized. I’ll dive into these concepts in more details, so let’s start with;

Testability

Everybody tests their code and there are two ways to do it;

a) Manually; set some breakpoints, fire up the app, input some data and push some buttons, let the debugger hit the breakpoints, inspect some variables, and check that everything works as expected (or more often; try to find out why it doesn’t work as expected)

b) Automated; use a testing framework like NUnit, xUnit, or MSTest, write some tests, and then let the machines do the tedious work of verifying that you didn’t break anything you didn’t mean to

If you enjoy your time with the debugger, I won’t try to convince you that automation is good. But I consider myself a pretty lazy programmer and whenever I see an opportunity to automate boring, repetitive tasks, I always try to do so. I prefer to code, not debug, and therefore I automate my testing. Therefore I write unit, integration and UI tests that can be run by an unattended build machine whenever I check in some code changes. I’m a coder, not a debugger.

But writing unit tests can be hard if you haven’t architected you’re classes and methods in a way that opens up for testing. If you instantiate objects inside your classes or in other ways are tightly coupled to other classes, mocking out those classes that are not in the scope of the current unit test will be hard. It’s not impossible, it’s just hard. One of the areas that are notoriously hard to unit test is the “code behind” of graphical components. Because when you instantiate a GUI component, it makes you dependent on a GUI thread when you run the test. On a build machine that’s going to run your tests without any interactive user logged in, this is just not the case; there’s no GUI thread available. And besides; it is bloody annoying and time consuming to have those forms and windows pop up whenever you run your test suite.

Opening your class for dependency injection and using an IoC container to manage the wiring of dependent objects is a well-proven and easy way to solve this problem. Prism explains and shows you how to write your application using an IoC container for the hot-wiring. And as I’ve already mentioned; if you prefer any other IoC Container, it’s totally up to you. But if you choose to not use Unity, you’ll have to be prepared to write some wiring code when initializing your application. Prism comes with the wiring code in form of a class called UnityBootstrapper. And there’s no surprise to the naming here; this class takes care of booting up your application with the Unity IoC container. So if you want to use any other container, you’ll need to rewrite the UnityBootstrapper to suite your choice. Or if you’re lucky; use the source code from someone who’s already done it (like the Castle Windsor adapter and bootstrapper that you can find in the Composite WPF Contrib project over at CodePlex).

 

All right! I think that’s enough for one post. I promised to write about maintainability, multi-targeting and modularity as well, so these will be the subjects for my next post.