ASP.NET MVC 5 Architecture, Identity, Unity

Question

Suppose a web project is associated with ASP.NET MVC 5 and OWIN / Identity. IoC runs with Unity. Now everything is in one project. Question: Does it make sense to split MVC, Idenity, and IoC into isolated projects and encapsulate Identity into some IAccountService that Unity will allow in the MVC project? The question seems pretty silly, but my rubber duck is silent for unknown reasons, any guess?

The goal I want to achieve is as follows

ASP.NET MVC (OWIN) -> IoC (Unity) -> AccountServiceImpl -> Identity

And MVC, IoC → Contracts (IAccountService)

where → project link

I need this to be able to modify the IoC container, and I also need Identity data to access from other projects through the interface

Answer 1

Yes, it’s safe to separate your solution from small projects like MVC, Identity and IoC.

At least my short answer.

Does it make sense? The long answer is a little trickier. I answered some similar questions before I turn to the architecture of solutions and projects:

• where should the interfaces be defined?
• Where should I put the automapper code?

In the answer above, I explained

[...] I have a typical structure:

• MyProject.Core
• MyProject.Domain
• MyProject.DependencyInjection
• MyProject.Infrastructure
• Myproject.web
• MyProject.Tests

Jeffrey Palermo encourages the use of Onion Architecture . In part 4 of his article on onion architecture , Jeffrey provides an example solution with the following structure

• Core
• Infrastructure
• IntegrationTests
• interface
• UnitTests

However, Jimmy Bogard somewhat disagrees with me and my approach.

In the evolutionary structure of the project , Jimmy explains:

I used to take a little care of the project structure in applications. Trying to provide logical stratification using physical projects, I would start a project by refusing to create an application with at least two projects, if not more.

Indeed, Jimmy describes his previously preferred style of solution architecture as being similar to the style I mentioned above.

Jimmy further says that “deciding on the structure of a project is a waste of time and energy.” He really prefers a simpler solution structure. That is very little .

Although Jimmy clarifies his position, saying:

I have absolutely nothing against the development of layered software. Using the project structure for this is a waste of time if you have only 1 application that you are deploying [...]

(Emphasis mine)

If you have other applications that require links to aspects of your MVC solution, it might be wise to separate them into your own projects so that you can easily reference them.

I think we should conclude that:

Solution architecture is not a rule or a law. Separate projects where it makes sense.

Make sure your decision is easy to maintain and easy to understand for others. Do not overcomplicate your decision.

Answer 2

I will add 0.02 ¢ to the excellent answer from Rowan. I will say more about the actual implementation of Identity.

As for the ASP.Net Identity framework, it can be a little difficult to move it from the MVC project to a higher (or lower, depends on how you place it) sitting layer. I'm sure you want to have an ApplicationUser object in your domain layer. But ApplicationUser depends on IdentityUser , which depends on Identity.EntityFramework , depending on EntityFramework . And adding EF to your domain project may be a little against the rules of onion architecture.

Also, the ApplicationUserManager from Framework Identity is massive (in terms of the number of methods), and also depends on EF. So hiding it behind an interface can be difficult.

So, you have 2 options:

• Take a hit and add EF to your domain project and at the ApplicationUser and ApplicationUserManager domain levels. And do not port the UserManager to the interface for several reasons.
• Take your luck differently and leave all the Identity materials in your MVC layer, define a very small set of actions to be performed from the domain level, and add a tiny interface on top of ApplicationUserManager .

I tried both and both approaches in different projects and both work equally well. I tried to add an interface on top of ApplicationUserManager and failed - mainly due to the size of the class, it is also designed to work in asynchronous mode, and there are sync-wrappers. Sync wrappers will not work with your interface - because of strong printing.

I wrote a blog post about applying DI to the Identity system , and there is a discussion in the comments on the separation of layers - take a look at the ideas.