Part 1: AspNet Identity and IoC Container Registration
Sounds like I’m making a series of articles about ASP.Net Identity and how to use it with Depenency Injection. Part 1 have seen a lot of hits from Google in just a few days. I suppose it is worth extending the tutorial.
Building up on Part 1 where I wired all Identity components to be injected by Unity container, now I’m going to add emailing service for email confirmation and password reset.
My plan is to use SendGrid as a email service and email debugging service Mailtrap.IO as a hosted fake SMTP server.
I’m reading a lot of blogs about development and .Net. One of the blogs I read is from Jimmy Bogard and one of the recent posts there is about guidelines for using Dependency Injection container.
I got involved in comments and one of the commenters was suggesting using
Func<IFoo> as injection instead of injecting the instance for
IFoo. And reasons for that were:
The “captive dependency” problem… objects with more constrained lifetime being held by objects with longer->lived lifetime.
The (wasteful) big-bang object graph problem… when an MVC action only requires 1 dependency, but the dependency graph for all dependencies within the controller need to be resolved.
The occasional property injection… when its 2am and I don’t feel like fixing a circular dependency issue (don’t hate).
CQRS architecture seems to be very popular. And I’m on that wave as well. In short CQRS is separating all read-actions from write-actions. And you have different classes for reading and writing. Queries for reading. Commands for writing.
For queries you would have IQuery and IQueryHandler interfaces:
public interface IQuery<out TResult>
public interface IQueryHandler<in TQuery, out TResult> where TQuery : IQuery<TResult>
TResult Handle(TQuery query);
For command you would have very similar set of interfaces:
public interface ICommand
public interface ICommandHandler<in TCommand>
void Handle(TCommand command);
There are doubts about if you should test registrations in you IoC container. I have been intimidated by this blog-post for a while and did not touch container for writing our tests. However, we did have a problem in the past, when DI container could not create one of our controllers. And we have lost days trying to chase the problem – there was no meaningful error message, because the real exception was swallowed somewhere in transit. It turned out that we have violated DI principal of a simple constructor: “Do nothing in constructor”. I have blogged about this before.
Today I would like to show how we test our IoC container to check if it can create all our controllers. Because controllers are immediate aggregate roots that are used by an end user. And controllers in MVC are the final consumer in the dependency chain. So if you likely to hit a problem in a chain of dependencies, it is likely that you will catch it by creating all the controllers.
Of course, if you use IoC container as a service locator or Mediator pattern you will have to test container separately for the types you get out from container there (mostly Command Handlers and Query Handlers).
ELMAH is a nifty tool that allows to you record exceptions that arise in your web-application. It is very handy and everyone should use it in addition to application logging. But if you are using Dependency Injection and have your connection strings provided by some service, then you might have trouble. For example, in our app, we use Azure Configuration settings and we have a service
IConfiguration that has a lot of get-methods for different config settings in our app, including database connection string.
In the previous blog post I wrote how it is important to have a simple constructor that only accepts dependencies. And violation of this rule cost me at least 12 hours of debugging and blocking issue for some developers in the team. Now I have a unit test to prevent this kind of problem in the future.
One of the suggestions in the comments was to use strict mocks and inject them into a controller. And don’t set up any kind of expectations on mocks. This way if dependencies are doing anything in the controller, they will fail the test.
Whole day of yesterday I’ve spent debugging some “random” error that came up third time during this week. The issue did go away after some tribal dances around the code, but two other instances did not get resolved easier. The biggest problem was that only one of the developers on the team did get the issue, and everybody else were not affected. And the same happened in the new deployment. And the issue was quite major – the whole site did not load. Nothing beyond the login screen. And it was impossible to hook in the debugger, it was bypassing all the breakpoints.
I would’ve gone through the issue and try debugging it, by my machine was not affected by the problem. I could not reproduce the issue locally. But on my home machine the issue came up. Strange I through, but was glad it came up – means I can dig my teeth deep in the problem and debug it.
Quite often for DI auto-wiring I need to find all classes that implement a certain interface or inherit from some base abstract class. And reflection for that is brilliant. But I can never remember how to find these types, so every time I need to look up my old code. So I’ll record that in this blog. Here you go:
var profiles = Assembly.GetExecutingAssembly()
.Where(x => x != typeof(Profile) && typeof(Profile).IsAssignableFrom(x))
This will give a list of types that all inherit from class Profile, but actually excludes the Profile class itself.
Ninject is very cool and lightweight DI container.
But you can not always inject objects through constructor – sometimes you must have parameter-less constructor, like in MvcApplication object.
In that case you can use DependencyResolver from System.Web.Mvc namespace from System.Web assembly
Unfortunately MSDN documentation does not have much, only link to this blog post: http://bradwilson.typepad.com/blog/2010/10/service-location-pt5-idependencyresolver.html