jp.hamilton

IE 8 Beta 2?

Anyone else having a hard time with it? It's crashing so much on me that I have found it to be unusable. The crashes are caused by something specific I think. There are certain web pages I just can't go to. For instance, every time I tried to read any comments on reddit, IE would jump the shark. On a positive note, it works with Google Maps now, but still...not worth the trouble. I uninstalled everything and went back to IE 7. I just don't need the hassles. I am finding myself using Firefox more and more every day because it just seems to be closer to zero friction. I don't know about you, but I am done fighting tools.

But That's Too Hard To Test

Just wanted to post an observation. I have noticed, lately, that if something appears to be too hard to test, I may be violating SRP. I am currently doing a large WinForms app that is utilizing MVP. I have noticed that I have a tendency to want my Presenters to do way too much work. How do I know this? I get a clue when I end up having to mock the entire universe in order to test it. This makes me really tired and then my brain starts going "forget about testing, we have code to knock out." This is not what I want.

I am not sure why my brain tells me "put everything in the presenter". It should be saying "break up that little piece of functionality and put it in its own class". Then I would be able to test this small piece of functionality independently of my presenter.

Anyway, I suspect that much of what I post about TDD, most people know. Again, I write about this stuff to share my hard won insights. TDD is hard and it takes a real commitment. You can read about something and still not know it. You gotta know it to know it, if that makes any sense. So, I guess what I am trying to say is this: if you are struggling with it, I am pretty sure that's normal.

This is not, nor ever will be, a VB.NET blog...

"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.

Mysteries of VB.NET

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

x = y = z = 0

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

Building an Enterprise Composite Silverlight Application

UPDATE: This sample has been updated for Silverlight 2.0 RTW.

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 != Dependency Injection

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.