"Then why do you write things about VB from time to time, J.P.?", you ask.

Well, I'll tell you. Because I am on a 2 year long project that is using it and I really dislike the entire point of the language and everything it stands for. You might as well go full retard. It's like telling a contractor he has to build you a house with a butter knife because you don't want him hurting himself with a saw. I'm sorry but you just gotta know stuff to write software. Accept it.

"Wow, J.P., just wow..."

Look, I am not going to justify it. It just is. Am I a language snob? No, not at all. I like many different languages out there. Python, with that wild white space thing...love it. C#? Love it the best. Ruby? Yeah, neat. LISP? Sure, why the hell not. Scheme, too, for that matter. F#? No problem here. Haskell? Scala? Great.

Every time I find something quirky in VB, I feel COMPELLED to send Paul Vick a message about. He's the VB architect....I think. He's up there in the chain of command anyway. The guy probably thinks I am trying to be mean about it, but seriously I am not. I just can't help myself. Anyway, I'm sorry Paul, I am not trying to be mean.

Dim x = 10
Dim y = 14
Dim z = 12

x = y = z = 0

Compile this. Look at the value of x. WTF.

A few weeks ago the Composite WPF (Prism) team put out a release which contained a port of the library for Silverlight. I looked at the reference applications and decided that I wanted to put together a sample that would help me figure out how to structure an "enterprise" application.

After looking at the reference applications that were provided with Composite WPF, I had a few questions:

1. How do I structure my application shell?
2. How do I host multiple modules?
3. How do I navigate between multiple "screens"?
4. How would I show dialogs?
5. How do I communicate between views?

You know, I am just guessing here, but I think I can structure this stuff just about any way I want. Composite WPF is just guidance after all. However, I think what I have done is in the spirit of the guidance. However, if I am off base, I am hoping some of you will let me know what I can do to improve the design.

With that said, you can look at my sample here.

Now, the first thing many of you will say is,"Wow, that sucks!" True, the demo is nothing special from a visual perspective. And let me tell you, my layout skillz are lam3!

I would say that anything worth looking at is in the code. The purpose of this exercise was really just to see how I could put together a composite application. I am interested in application structure from a UI perspective, not visual appeal. Also, this is a work in progress. I will be doing more with this in the near future.

My design relies heavily on inversion of control (as does the guidance itself) and I am using Model-View-Presenter (MVP). Rather, I should say View-Presenter. My sample does not have any need for a model...yet. Again, I wanted to focus on building multiple composite views and connecting them together within the context of an application shell.

The sample has two modules, Alpha and Beta. Each provides "menu" items which are added to the application shell when the module loads. These commands can be invoked to display several different views.

The Alpha modules contains many points of interest including the use of WPF commands (or port of them I should say), wiring up MVP, scoped regions, and using the event aggregator. I know the code is primitive. There are several areas that are ripe for refactoring. There is a bug with one of the views that uses the event aggregator. It never unsubscribes from the event.

Also, the modules are not dynamically loaded; they are directly referenced by the primary Silverlight assembly. That's not the greatest thing, but StaticModuleEnumerator is the only module enumerator that has been ported at the time of this writing.

But with that said, I still like where the sample is headed. Over time it will get better, I'm sure.

You can download the code here.

Inversion of Control facilitates dependency injection. It is not the same thing. But more on that in just a sec.

Jeffery Palermo has been writing that inversion of control is not about testability. I agree, IoC, is about loosely coupled designs. He then goes on to say there is no such thing as loose coupling, which I wholeheartedly disagree with. The is no such thing as no coupling, but coupling to an interface is far more flexible than being coupled to a concrete type. Hence the term loose. Ok, now that I have stated my opinion. I want to write a bunch stuff to see if I understand IoC, because I see a lot of terms getting overloaded and it confuses me. So...

Here's how I see the world. There is this design principle called the Dependency Inversion Principle which states:

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

Wow, what does that mean?! Well, think of a typical layered architecture. What this principle is saying is that the layers in an application should be coupled to interfaces or abstract base classes (interfaces are better), not to each other. That is, the UI Layer should not just "new up" a Service class and use it. Also, I shouldn't write methods in the UI Layer that refer to concrete types in the Service Layer.

If I accept that this is a good thing, how would I build such as system? After all, the UI Layer does, in fact, need something from the Service Layer, which in turn relies on stuff in the Data Access Layer. The answer to this question of course is dependency injection, which simply means that I would pass the Service dependencies that my UI object needed at the time it was created. This is typically done via the constructor. In this way, the UI object would not create any instances directly. It's getting everything it needs through its' constructor.

Ok, sounds good on paper, but how would this be accomplished? It seems that some code would need to exist somewhere (or would it! dun dun duuun!) that would be responsible for creating these dependent objects in the first place. And that code would be tightly coupled to something, maybe some kind of Factory assembly that was responsible for creating everything. 

However, there is a better option: Inversion of Control. With IoC, I essentially request the objects that I need instead of declaratively telling the system to create the specific objects I want. That is, I say "Can I please have something that implements IEmployeeService" instead of "Gimme an EmployeeService, fool".

This style of programming is accomplished with an IoC container (personally, I like the Windsor container). The container is configured in some way, either in code or some form of external configuration file. The configuration defines what objects should be returned for what requests (e.g. a request for IEmployeeService should return an EmployeeService3). In this way, you can think of an IoC container as a big bucket o' objects...on pirate ship...floating in a sea of chocolate. 

The IoC container automatically creates the objects that are requested. If those objects depend on other objects, which also happen to be configured in the bucket, it will create those, too, and inject them into the requested object.

A side effect of all of this, of course, is testability.

I saw an interesting post from Ben Scheirman last Saturday on the separation of concerns with regard to ASP.NET MVC controllers. Apparently, Preview 4 includes a new AccountController that contains some...ahem...less than production quality code. Ben refactors the code and gives it a more professional polish and the story ends happily.

However, what I found most interesting was one of the comments to his post. And I quote:

"I'm beginning to get a distaste for controllers. It seems like too much code in one place."

To me, this is a very interesting comment because it is characteristic of something that I notice quite frequently: people seem reluctant to create new classes even when new classes are required (disclaimer: sometimes "people" means me). They seem to get into a mind set that certain code needs to go in a certain place versus thinking about classes in terms of behavior. I see this from developers across all levels of experience, too.

Unfortunately, this way of thinking leads to an anti-pattern that I like to call Swiss Army Knife. This is the class that does it all and behaves however you need it to behave.

Here's the thing. We all know this is not a good thing. Whether we have a controller, a view, a presenter, a repository, or a whatever, a class is about behavior. It is there to do a specific job. When we notice that our class is starting to exhibit a split personality, we break it into two classes. No need to be afraid. Code is the most malleable substance on the planet. If we don't like the results, we can always refactor and try again. I know this is common wisdom, but it seems that under certain circumstances, we just forget to do it.

I am going to go for it. It contains fixes for 7 bugs that I reported plus a slew of other fixes. I have to say that I really like the way Jetbrains handles their bug fixes. When you report a bug, you are notified when the bug has been assigned to a developer as well as when it is fixed. When a build is done, it is easy to see if bugs that you reported were fixed. Compare this to the "send and pray something will get done" method employed by many MS programs. Seriously, I wonder where all my bug reports to MS go. No visibility whatsoever.

I have to say that last nights dinner was a success. Although, I must admit I am easy to please. If I learn a new keyboard shortcut I consider it time well spent. For instance, I had no idea you could jump to type declarations using Resharper by holding the CTRL key and dragging the mouse around. It's really cool. ReSharper underlines all your types and basically turns them into hyperlinks. Conversely, a colleague of mine did not know Shift+Alt+L would allow you to jump to a file in Solution Explorer. See, this is why geek dinners are good.

Anyway, we discussed the Entity Framework Vote of No Confidence,  our favorite tools, and putting together an Open Spaces event sometime at the end of the year (beginning of next year?). To top it off, Jay Sawyer (a very cool Microsoft guy) was there, and picked up the tab. Thanks Jay!

Okay, that's all I've got, so I will leave you with one final bonus keyboard shortcut  (that I learned yesterday from my co-worker Eric Geiger who always seems to have cool tips): Holding down CTRL turns the IntelliSense window transparent so you can see the code underneath it. Ta da! How did I not notice this before now?

I just happened to check the ReSharper nightly builds today and to my surprise there was build 900 sitting there. I checked the associated bug fixes and there were too many - at least 4 pages worth - for me to go through them all. The build date shows today. I am going to go for it and install it.

It is ridiculously simple to compile code dynamically using the .NET Framework. Most of the code is merely setting up the parameters you need to pass to the compiler. Once that is done, basically, you have a 2-liner on your hands. We are using the technique to provide formulas to a bidding system that we are working on. Essentially, the code looks like this:

using System;
using System.CodeDom.Compiler;
using System.Reflection;
using Microsoft.CSharp;

namespace AppUtils
{
    
    public class Compiler
    {

        private static readonly CompilerParameters parameters;

        static Compiler()
        {
            parameters = CreateCompilerParameters();
        }

        public static CompilerResults Compile(string code)
        {
            var provider = new CSharpCodeProvider();
            return provider.CompileAssemblyFromSource(parameters, code);
        }

        private static CompilerParameters CreateCompilerParameters()
        {
            var assemblies = AppDomain.CurrentDomain.GetAssemblies();
            var options = new CompilerParameters
            {
                GenerateInMemory = true,
                GenerateExecutable = false,
                IncludeDebugInformation = true
            };

            foreach (var loadedAssemblies in assemblies)
            {
                options.ReferencedAssemblies.Add(loadedAssemblies.Location);

                foreach (var reference in loadedAssemblies.GetReferencedAssemblies())
                {
                    var referencedAssembly = Assembly.Load(reference);
                    options.ReferencedAssemblies.Add(referencedAssembly.Location);
                }
            }

            return options;
        }
    }

}

As I have said already, I am pairing down Visual Studio to the bare bones. I have decided that when is comes to the IDE, less really is more, at least when it comes to "stuff that is visible when I am writing code". Currently, I run with no toolbars of any kind.

I had been docking non-code windows (Solution Explorer, Properties, Team Explorer, etc.) unpinned to the right side of the screen. However, I noticed that I would accidentally un-auto-hide (hmmm) these docked windows randomly throughout the day. This is annoying.

Now, I keep these windows undocked (floating) and off. If I need Solution Explorer, I just use CTRL+ALT+L. Or if I need Properties, I hit F4. Then, when I am done, I close the windows. Stare into the void:

The only bad thing here is that I am crippled with the VB language, which is out of my control. And I only mention that because I like to take a jab at VB whenever I can.