On Saturday May 30th I attended the first ever Chicago Code Camp. Thankfully it wasn’t actually in Chicago, but closer to Wisconsin which made the drive bearable. I rode down with Steve (thanks for driving) and I-Lin, and met up with Lance down there. Overall, the event was a great success I think, and it’s something we’d like to put on in Madison sometime in the near future.

Session #1 – Introduction to AOP with Post Sharp by Michael Hall

This was a good introduction to Aspect Orientated Programming (AOP) using Post Sharp (.Net Environment). I’ve looked into Post Sharp before when it first came out, but it looks like it has come a long way in terms of stability and features.

AOP involves moving code which implements non-functional requirements such as logging, security, transaction management, into Aspects which can be then applied across your application. Another term for non-functional requirements would be cross cutting concerns. An aspect can be though of as a class, and is made up of advice, or methods.

A common example used when describing AOP is the cross cutting concern or non-functional requirement of tracing. Typically, in each class where you require tracing, you will create a static read-only variable for your tracing object, and then in each method, you will call Trace.Write(). With AOP, you can apply an attribute to the class to perform tracing for all methods, or on specific methods. When the method is invoked, the tracing code is executed, either before and/or after the method body depending on how the aspect is coded. The advantage in this scenario is that you do not have to declare that tracing variable or write the code to write the trace statement every time. This way if you need to change the way the tracing works, you only have to do it in one location.

Post Sharp provide a framework for building and applying the aspects. The aspects are applied at compile time by injecting code into the compiled MSIL code. Aspects are created as attributes by inheriting from several Post Sharp base classes, which include:

• OnMethodBoundaryAspect: Used with code you own. Allows for code to be executed before and after the method body.
• OnMethodInvocationAspect: Used with code you do not own, allows for code to be executed before method.
• OnExceptionAspect: Code to be executed if an exception occurs.
• OnFieldAccessAspect: Code to be executed when a field is accessed, providing for property getter/setting like functionality on fields.
• CompositionAspect: Change code at compile time. For example, you can force a type to implement a specific interface.

Out of the box, Post Sharp gives you an incredible amount of functionality with those base classes, but you can add new custom aspects if needed. Normally Post Sharp needs to be installed with the MSI installer since it is integrating with Visual Studio. However, instructions are available for an XCopy deployment.

Session #2 – Guarding your code with Code Contracts by Derik Whittaker

Code contracts is a project from Microsoft Research which is being integrated into VS2010, and is available in VS2010 Beta I, or as a download for VS2008. Code Contracts are a way to define static assertions at design time, to be validated at compile and run time.

You probably have written a “code contract before”, but have never realized it. A simple example is where you check to see if an object is null at the beginning of a method, and if it is, you throw an ArgumentNullExpcetion. The Microsoft version of Code Contracts replaces the If Then Throw convention with Contracts.Assert(boolean expression).

So why is the Microsoft Solution better? The Microsoft solution integrates directly into Visual Studio giving you support for Static Analysis at design time. This means that if you call a method with a Contract.Assert(paramter != null) and pass in null, you will get an error at compile time, as well as a warning in the form of a squiggly line under the method call at design time. Automatic testing tools like Pex can take advantage of the code contracts as well.

The real power of Code Contracts can be seen when you look at some of the advanced contracts offered. For example, you can validate that a return variable is not null, as well as validate a condition every time a method is called using the Invariant contract.

Run time errors are displayed using Debug.Assert behind the scenes. This is automatically disabled in the build type is set to release. You can also handle the debug assertion yourself by implementing an failed contract event handler.

Session #3 – Fluent NHibernate by Hudson Akridge

This was an excellent session and probably my favorite of the conference. Hudson is a member of the Fluent NHibernate team, so he obviously is an authority on the topic, and also has a deep passion for Fluent NHibernate that is hard to reproduce. Hudson had all of his demos compiled and running ahead of time. He simply created new projects and used printed copies of the source to type from. This saved a tremendous amount of time. When time did start to run out, Hudson simply switched over to his already completed projects to finish things up. Memo to presenters, follow this approach!

The Fluent NHibernate (FNH) wiki, as well as the project members blogs provide an excellent amount of documentation, that I simply can not duplicate in this blog post, so be sure to check out those resources.

FNH is built on top of NHibernate, and it’s purpose is to replace the NHibernate Mapping Files (HBM) with a strongly typed fluent interface, with the goal of making the use of NHibernate easier, while producing more maintainable code. It succeeds on both fronts.

FNH provides two mapping options, AutoMapper, and Fluent, both of which can be used at the same time. AutoMapper uses a convention based approach where Property and Class names map to tables in the database. This is great for simple domains and green field projects with simpler database schema requirements. The fluent interface provides for a much more granular approach to mapping, and currently supports most of the functionality provided by HBM files (most people will not know that anything is missing). The fluent interface allows you define conventions which allow you to reduce repetive mappings. For example, if all of your entities have an integer based Id field, you can define that, saving yourself from having to write the mapping code over and over.

FNH does have some limitations, such as, all properties must be public. Obviously there are some situations where this is not desirable, so you could switch to HBM files, or utilize on of three work-arounds for fluent. The first two involve nesting code at some level, while the 3rd involves the use of strings to identify the non-public field names. While you loose the strong typing and compile time checking, I think I like the string option the best.

Two general tips I learned during the session, was to always make your public properties virtual so that NHibernate’s default behavior of lazy loading will work. Hudson made the comment that you should not try to outsmart NHibernate’s lazy load mechanism. The only time you should consider eager load is if you have to detach your object from the NHibernate session. The other tip was the feature that allows you to generate a complete database schema from the NHibernate mappings. From comments I heard in the crowd, the schema generation is very impressive compared to other ORMs.

Session #4 – Mass Transit by Dru Sellers

Mass Transit is an Enterprise Service Bus (ESB) written in .Net 3.5 and is designed around simplicity and speed. I had a general idea of what Mass Transit was going into this presentation, and was hoping I would learn that it would be directly applicable to a project at work. However, it’s a little too much functionality for what we need, and that’s not a bad thing, as we could probably make use of it in the future.

While I have no immediate need for an ESB at work, I was very impressed with the .Net 3.5 syntax the project uses to handle subscriptions. I’m currently starting a prototype project that could make use of an in memory service bus, and I think I will be reviewing the Mass Transit source to see what I can borrow.

Coming from a BizTalk background, a lot of the features and functionality was comparable. However, whereas BizTalk costs money, Mass Transit is free, open source, and would probably meet the needs of most organizations. Both of the authors (Dru, the presenter is one of them) use Mass Transit daily in their jobs in the banking industry.

Session #5 – Solid WPF by Michael Eaton

This presentation could have been titled WPF and the MVVM pattern. Not that Solid WPF is a bad name, but for those of you at home, it was a talk on MVVM with some YAGNI thrown in for good measure.

This is not my first MVVM presentation, and it probably won’t be the last. Unfortunately I’m still struggling to fully understand the pattern, which is partly due to my lack of experience with WPF (which I need to remedy soon).

However, the approach that Michael took in presenting MVVM was different, in that he started with a WPF app coded using just the code behind, then did a copy/paste to a new project and tried a MVC pattern, and then finally worked in MVVM. Seeing the transformation of the application from the first to the third project did help solidify some of the MVVM concepts.