Leandro Boffi

In order to create maintainable and flexible architectures you must start to split your code responsibilities into several components, each of them with a single responsibility, but also low coupled.

Let me show you what it means. To make it clear lets choose a common scenario:

UsersRepository is a component that has the responsibility of Users persistence and storage, and UserService is a component that has the responsibility of applying business rules, like validation for example. As you can see in the diagram UsersService maintains a dependency with UsersRepository, this is how it looks in the code:

This is a poor design, due that it creates a hard dependency between both components and that’s no good for maintain and test reasons.

It’s clear that this hard dependency will create problems at maintain time, or if we need to do changes, in the other hand if you work with TDD, or you just want to use automated tests, you probably should test each component separately. This means to test the UsersService without testing the UsersRepository and vice versa.

Let’s start to decouple these components, to do that I need to introduce to you the Design by contract approach. We will start by creating an interface for the UsersRepository that will act as contract. The UsersService will use the UserRepository through this contract:

By using a contract we are changing the rules of the game, instead of using the component we are using his functionality through an interface. It means that if we need to migrate our repository from ADO.NET to LinqToSQL or instead of use a database to save our objects we use xml files or webservices or whatever, we just need to create a component that implements this contract and change only one line of code in the service. Let me show you how looks the service with this new design:

We did it. We have removed the hard dependency, and now our components are low coupled. This is our UML components diagram updated:

Ok, now let’s take it to the next level, by making the UsersService friendly for unit tests, to allow test it without testing the UsersRepository. We need a mechanism that allow us to replace the real UserRepository for an mock in testing time. Let me quote Martin Fowler, from his article Mocks aren’t Stubs:

A mock is and objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Here is where dependency injection comes to play. Dependency injection, also known as Inversion of Control, is a great solution to create testable components and his implementation is really simple. We just need to provide a constructor that accepts an IUsersRepository as parameter, and also, for practical reasons, a default constructor with the default implementation. This is how it looks:

Note that the constructor that provides the dependency injection ability is marked as internal. This is because we don’t want to any body from any where be able to use it, from outside they will only view the public constructor, that constructs the service using the default implementation.

Here goes one little trick: to make your internal types visible form other assembly, like a test project, you need to add this line in your AssemblyInfo.cs file:

Just replace “DependencyInjection.Service.Test” by your test project and it’s done.

That’s all, now our components are low coupled, and also we have a testable UsersService, we can even test and create (note I said test before create) our UsersService without have the real implementation of the UsersRepository,  and it is just how it must be.

Hope be useful!

The first time that I saw ASP.NET MVC, I was at a Microsoft Tech-night, the speaker was my admired co-worker, Edgardo Rossetto, and I felt in love with the framework. It brought me many memories about my ASP 3.0 developer time.

ASP.NET MVC is not a replace for ASP.NET Web Forms model, is just another choice, and I really like, because I’m a patterns lover and, as you can imagine, ASP.NET MVC is based on the famous MVC Pattern, but also is great because enable easy Test-Driven Development, and every single action is easy mapped to a REST-friendly URL.

So, given that, I want to share with you a little home-made project, my own ASP.NET MVC Grid View.

Before you feel so excited, it do not support paging and sorting (yet), but you can easily add these features in your controller. Right now, it supports simply “Data Source” (any IEnumarable object), extensible “Column Definitions” and CSS Styles.

How to use it?

This grid View is basically composed by a Web Control, and a set of “model” classes.

The data (DataSource, ColumnDefinitions, CSS Styles, etc…) is given to the WebControl as ViewData. Let’s see that…

Mock Data (Just a method that returns a list of users):

Controller example code (DataSource & Column Definitions at Controller):

View example code:

The result:

How does it work?

The method in change of render the value of each field is place in GridColumnDefinition base class. As you can imagine, it’s based on reflection, using the value of PropertyName to find the value to render.

This is the magic method:

Here we’ve something cool; this method is also based on Template Method Pattern, to allow formatting the value before render, so you can write your own implementation of the FormatValue method.

I’ve written three as example…

This is the GridImageColumn implementation of FormatValue, to render an HTML image with the value…

Perhaps an “Action” column definition can be implemented giving as value the Id; it’s free to your imagination!

You can download the source code here.