Griffin.Container: Register services using your own attribute.

As you might now, I recommend that you register most classes using the [Component] attribute. However, you might not want to add an external dependency to all class libraries. You can avoid that now with a new feature. And that is to use your own attribute.

You can of course use the feature to customize the registration process. Let say that we’ve created a new attribute called ContainerServiceAttribute, so that we can decorate one of our classes:

public class SomeService

To register all classes with the new attribute use the following:

var registrar = new ContainerRegistrar(Lifetime.Transient);

// the new magic.

var container = registrar.Build();

The attribute itself is responsible of the registration. Here is a simplistic example:

class ContainerServiceAttribute : Attribute, IAttributeRegistrar
    public void Register(Type concrete, IContainerRegistrar registrar)
        //concrete = decorated class. In this case "SomeService"
        registrar.RegisterConcrete(concrete, Lifetime.Default);

Use the type to decide which interfaces etc that the class should be registered as.

The feature is available in version 1.0.3. Install it using nuget.

Code is available at github.

Resolving all services through dependency injection in Griffin.Container

I’ve just added a new feature to Griffin.Container: Support for resolving all implementations of a service by using constructors.

You can now do something like this:

public interface IStatefulService
	void Ping();

public class FtpConnection : IStatefulService

public class Pop3Connection : IStatefulService

public class ConnectionPinger
	public ConnectionPinger(IEnumerable<IStatefulService> services)
		_services = services;
	public void PingAll()
		_services.Each(x => x.Ping());

Griffin.Container can be found at github.

To “var” or not to “var”, is that really the question?

There are several blog posts and discussions about whether to use var or not. They tend to focus on whether the type is obvious or not. It seems like people are afraid to suddenly be writing code in a dynamic language just because they can’t read the type anymore. I got news for you: You’ll still get a compiler error and an intellisense warning if you pass the wrong type to a method.

A most common argument is that “var” should only be used together with LINQ. That makes no sense. Why is it acceptable to use with linq? Because it makes the code more readable than writing the complex type? You got it! 🙂

The fact is that the type isn’t that import anymore. Your business object probably got several representations today. You got your Entity Framework entity, your WCF service DTO, your ASP.NET MVC view model etc etc. That is, you have several representations of the same information which you work with. The actual type doesn’t really matter since it’s only valid in it’s own layer/class/scope. If you by mistake got another representation than your intended one, you’ll get feedback instantaneously from Visual Studio.

Is this code hard to read?

public ActionResult Create(UserViewModel model)
    var user = _repository.Create(model.UserName);
    user.LastName = model.LastName;

    var admin = _user.Get(user.Id);
    var email = _emailFactory.Create("RegistrationEmail");
    email.SetTemplateTag("userName", user.UserName);
    email.To = admin.Email;

    return RedirectToAction("Index");

The fact is that the type is only important when you use crappy names:

User a = myObj.Get(1);

instead of

var admin = userRepository.Get(1);

As a developer you should always strive after writing as clean code as possible. Using var will shorten the code and therfore make it more readable. It will also move the focus from the types to what the code actually does.

Finally, here is my favorite motivation against “var”:

When I write code, not only do I think about performance and maintainability, I think about perhaps someday migrating it to another language. As such, I rarely use “var”.



Many objects today are complex (i.e. not primitive or just having primitive properties). How do you treat them?

Do you type your code like this:

User user = _repos.Get(1);
Department department = user.Department;

instead of:

User user = _repos.Get(1);

Of course not. Why not? Because given the context of the user, it’s obvious what the department type is. Same thing goes for when using your services, repositories and similar. If you load the user from a repository you know that it’s a db entity. No need to show the type.

Updated the localization administration area

I’ve updated the administration area for the localization features in an attempt to make it easier to handle the localization.

I’ve replaced the link texts with icons so that they take less space. I’ve also added filtering options (so that you can translate one area/controller at a time) and a filtering option which allows you to only show texts that hasn’t been translated yet.

Update the nuget package (“griffin.mvccontrib.admin”) to get it.