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).
Tony Mackay has an alternative walk-through of a very similar process but with Autofac
Part 2: Sending Emails in Asp.Net Identity using Dependency Injection, Sendgrid and debugging it with Mailtrap.io
Warning: If you don’t know what Dependency Injection is or you don’t know why you need this, don’t waste your time on this article. This approach is not recommended for cases when you don’t need a IoC container and have only a handful of controllers. Visual Studio template with Identity framework works great out of the box. You don’t need DI to enjoy full power of Asp.Net Identity. This article does not explain what DI is, how it works and why you need it. So proceed with caution and only if you know the difference between constructor injection and lifetime scope.
I regularly monitor StackOverflow for questions related to AspNet Identity framework. And one question keeps popping up over and over again: how do you use Inversion of Control containers with this framework.
If you know the main principles of Dependency Injection, things are very simple. Identity is very DI-friendly and I’ve done a number of projects with Identity and injected all Identity components via Autofac or SimpleInjector. The principles behind DI are applicable to all the containers, despite the differences in API’s for registration.
For the sake of this blog-post I’ll start with the standard VS2013 template and use Unity container, just because I’ve never used Unity before. You can view registrations for SimpleInjector in my test-project.
Projects where I used Autofac are far too complex to show as an example and none of them are open-source, so Autofac fans will have to figure out themselves from my examples.
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).
One of the crucial bits of application in cloud is logging. Trying to debug in a cloud without logging feels like a little blind kitten trying to find plate with milk. At some point of our application, we just HAD to add logging of what is happening with our app in Azure.
In .Net world there are few major logging frameworks. Our choice fell with NLog for reasons I can’t remember. But it worked out fine and I would not want to change it to something else.
After playing with NLog for a bit, next question was WHERE to log to. Where to store logs and how to manage them? That was a big question. In Azure you can’t just log stuff to files. With next deploy, you’ll loose all your logs, because Azure wipes clean VMs and create a fresh one with new deployment. You could store logs in SQL tables, but imaging how much we would pay just for storage of SQL data. And logs for business people are worthless. Business only wants new features and bill clients for them. They don’t care how we do it, as long as we do it. So expensive options were out of question.
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.
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.
Quartz.Net is an awesome scheduler for .Net world. It is a copy-cat from Java brother. The documentation is pretty useless, as it has not been updated for a while. The docs are useful to understand the general principals of operation, but examples of code usually don’t work. Instead the download provided on the site has a lot of examples. Use them as a guidance. Read the code, documentation sucks.
Anyway, I’ve spent couple days trying to get Quartz.Net to work inside of Azure and with Autofac dependency injection. And there are a few lessons that I’ve learned that I would like to share.