At Tech-Ed last week they offered the ASP.NET 3.5 Beta Exam. The beta exam is not available in Phoenix, so I decided to give it a whirl on Thursday. I didn't plan to take the test so I didn't have a lot of time to review (maybe 30 minutes of review) and I just dove in and took it.

Normally MS Exams have about ~40 questions and they take a couple of hours for me to complete. I was expecting the same from this one...

Nope. This exam had 70 questions. Wowza. I'm assuming the reason for this is one of these scenarios:

• This is a beta exam and they need to weed out some questions
• They have bumped up the number of questions in the exam

So how hard was it?

Well ... it's a little harder than the 2.0 version. A lot of it is repeated from 2.0, but this new beta exam threw me for a loop in a few areas.

The areas that threw me for a loop were:

• WCF Integration Questions (I'm very well vested in WCF, but I just was not expecting it in this exam - there's a WCF exam for that!)
• Deep AJAX Questions (Don't do much AJAX stuff, lets be honest... JavaScript is not my favorite language)
• Miscellaneous Mobile Questions

The main thing about MS exams is that they are LONG and tricky. Sometimes you'll get asked a question and all four answers look right. LOOK VERY CLOSE. You'll see that maybe one word is spelled wrong, or the line's are swapped, etc. They will confuse you. But the main thing to do is be alert. The test will wear on you, its long. By the 2.5 hours in, you'll get tired of the test and you'll want to just hurry through it, don't. Just take your time.

So How Did I do?

Since its a beta exam, I won't know for about 2-3 weeks. They send your results in the mail. I feel like I passed, but we'll see when the results come in.

... and no, I didn't take any pills before or after... :) I'm just joshin' ya'll.

This past weekend I presented the topic "Intro to Dependency Injection and Inversion of Control" at the Phoenix Desert Code Camp. A big thank you goes out to everyone who attended. It was such a popular topic that it actually moved up to the largest room in the conference location, the Theater at UAT! Thanks again everyone!

At the bottom of this post are the resources from this presentation.

Resolution from Error During the Presentation

For those of you were present when I ran into an issue with this "DynamicMethod" error, I have figured out the issue. It's a bug in Unity. It looks like its been fixed and should be available in the next release.

I was able to work around this issue by moving the Dependency attribute into the Interface. I have updated the code in the download below to reflect this.

Presentation Resource Download

Full Solution Download (900K)

PowerPoint Presentation

You can also view the presentation online - located here.

Note: A full solution is supplied at the bottom of this post if you would like to download it and run it.

A couple of days ago Matt wrote about the new Unity Application Block. The Unity MSDN article describes Unity as:

The Unity Application Block (Unity) is a lightweight, extensible dependency injection container. It facilitates building loosely coupled applications and provides developers with the following advantages:

• Simplified object creation, especially for hierarchical object structures and dependencies
• Abstraction of requirements; this allows developers to specify dependencies at run time or in configuration and simplify management of crosscutting concerns
• Increased flexibility by deferring component configuration to the container
• Service location capability; this allows clients to store or cache the container

Designing a software system architecture with loosely coupled components makes life easier in the long run. A few of the benefits of loose coupling are : maximizing testability, modularizing components, and increase the maintainability of the code.

This is a simple introduction into Unity that exemplifies the simplicity of the container setup. I will cover two options for type registration:

1. Manual Method based type Registration
2. Configuration file (XML Based) type Registration

The Example Application

The application that is included at the bottom of this post is visualized via the class diagram below. This simple application utilizes very simple implementations of the repository, mapper, domain model, data transfer object (DTO) and service layer patterns for example purposes.

The application follows a very simple flow as shown below:

The console application calls into the Service layer which calls into the repository to get the data which calls into the DB. A domain object is created from the Repository call, which is passed up to the service layer. The Service layer returns a DTO via the DTO Mapper to the parent caller (the console app) and then the console app displays the customer name via a write line call.

None of these layers have any inter-dependent dependencies coded inside of them. I'm using constructor injection to inject dependencies into the calling object.

Once unity is set up, it will find the dependencies and supply them to the program at runtime. Therefore, if I need a ICustomerRepository for the service layer to work properly, Unity will give the Service layer a CustomerRepository instance. Since CustomerRepository inherits from ICustomerRepository Unity is able to make this link (once you've set it up) and supply the proper instance.

Class Diagram

The Setup & Code

The easiest way to see HOW Unity works is to get into the code. My recommendation is to download the sample below, fire it up in Visual Studio and set some break points to see how the code is interacting. Seeing is believing!

Before Unity can supply your application types at runtime, you have to tell Unity WHAT you want it to supply and where to find it. This can be done multiple ways as described here. Today we will go over manual configuration inside of the console app, and xml configuration.

Manual Configuration

The manual configuration that I've utilized here utilizes the fluent interface of the container.

Explanation of code: Here we are telling Unity to register a type. We're saying "If someone requests ICustomerRepository, give them an instance of CustomerRepository. If someone requests ICustomerDTOMapper, then give them an instance of CustomerDTOMapper. ..." and so on.

Using the Container From Manual Configuration

After you've set up the types of objects the container should resolve, you can then ask the container for a instance of "ICustomerService" and then invoke a method call on it. At this very point in time Unity will give you the CustomerService, and then when the customer service needs a repository Unity will then give it a instance of CustomerRepository, etc. At this point in time, everything is mapped for you behind the scenes. The only thing you have to do is ask for the first object and Unity will walk the dependency graph and fill in the blanks for you (if as long as you've given Unity the proper types it needs).

Here's how to do this in the code:

XML Configuration

XML configuration utilizes an external XML file (app.config/web.config) to create its dependency graph. This allows for a lot more freedom in what you would like to do with your app. If you're not happy with a certain version of "ICustomerRepository" you can create a new one, drop the DLL in the bin folder and change this config file to point to the new one and you're done. No recompiling!

In this implementation I'm using the app.config file because this is a Console App for example purposes. The full schema for XML configuration can be found here on the MSDN.

To utilize the XML configuration you'll need to utilize a custom config section. You can do this by placing this code into your config section of your app.config file:

Next, you'll need to add the container and type definition as shown below (this is just a snippet, full code is included at the bottom of the post):

The container gets its types from the config file at runtime.

Each type is declared in the config file as the "type" of object to find and the "mapTo" defines which object to return when the "type" is requested.

The type definitions are declared as type, assembly.

Using the Container From XML Configuration

To force Unity to use the XML Configuration you have to perform few extra set up steps in the application code as shown below. Essentially you're telling Unity that it's configuration/mappings are stored in a config file. The config section configures the container for you, as shown below.

To have Unity resolve an instance, its the same as the manual configuration option above. Here is the same image from above that displays how to do this:

Conclusion

Overall, using Unity as quite simple for this example. The docs on MSDN were pretty good, however I didn't really like the examples that were contained with the download because they did not show you how to utilize XML configuration as I wanted to. It didn't take but a few minutes to figure out what I needed to do. I think Unity is a decent solution at this time. I plan to investigate further into the depths of Unity to see if it may possibly be an alternative for my favorite container tool, Windsor Container.

Download The Code For This Post

FooTheory.UnityExample.zip (~477K)

Rhino Mocks and NUnit both have a "Is" keyword, both used for a fluent style of syntax. Unfortunately this causes testing problems when you need to use them together. The .NET compiler can only understand one "Is" keyword at a time. We can't use both unless we full qualify the second one.

Having said that, I've fully qualified the "Is" keyword for Rhino Mocks and NUnit before and I find it clunky and I feel its a code smell to me.

In the figure below an example of a fully qualified "Is" keyword for Rhino Mocks is declared.

 1 [Test]
 2 public void ExampleTest()
 3 {
 4     // ... items ommited for brevity
 5     
 6     With.Mocks(mockery)
 7     .Expecting(delegate
 8     {
 9        Expect.Call(databaseMock.GetStoredProcCommand(null))
10            .IgnoreArguments()
11            .Constraints(Rhino.Mocks.Constraints.Is.NotNull())
12            .Return(databaseCommandStub); 
13     })
14     .Verify(delegate
15     {
16         IQuery query = ExampleResultQuery.GetInsertResultQueryFrom(someparameter);
17         IDatabaseCommand command = query.PrepareCommandUsing(databaseMock);
18         Assert.That(command, Is.SameAs(databaseCommandStub)); 
19     }); 
20 }

On line 11, we can see the fully qualified name: Rhino.Mocks.Constraints.Is.NotNull() method called.

This, my friends, is a code smell (IMO).

How To Fix

The NUnit testing framework provides a "Iz" syntax helper that VB.NET developers use because "Is" in VB.NET is a keyword.

Since we're using .NET Managed code we can use the Iz keyword and it will achieve the same results as Is did. Therefore we can use the Is keyword in Rhino Mocks and we can use the Iz keyword in NUnit. This saves a lot of key strokes over the course of a day.

Final Example:

 1 
 2 [Test]
 3 public void ExampleTest()
 4 {
 5     // ... items ommited for brevity
 6     
 7     With.Mocks(mockery)
 8     .Expecting(delegate
 9     {
10        Expect.Call(databaseMock.GetStoredProcCommand(null))
11            .IgnoreArguments()
12            .Constraints(Is.NotNull())
13            .Return(databaseCommandStub); 
14     })
15     .Verify(delegate
16     {
17         IQuery query = ExampleResultQuery.GetInsertResultQueryFrom(someparameter);
18         IDatabaseCommand command = query.PrepareCommandUsing(databaseMock);
19         Assert.That(command, Iz.SameAs(databaseCommandStub)); 
20     }); 
21 }

Please note: Line 12 has the normal "Is.NotNull()" call from Rhino Mocks, and Line 19 utilizes the Iz syntax helper from NUnit.

I find this much easier on the wrist. :)

That's right! I will be presenting at the Phoenix Arizona Desert Code Camp on May 31st 2008.

I will be presenting a course on Dependency Injection / Inversion of Control. The time's have not been posted yet but as I find out more information I will update this blog.

I hope to see you there. Click here to sign up for the code camp.