So when starting a new web project (ASP.NET mostly) I always end up arguing with myself: Where do I keep the Authentication logic, the User entities and how do I combine them with my other business logic (e.g. Repository)? And what if I need session variables in my business logic?

So we have the following items, already defined in a template MVC application:

  • ApplicationDbContext
  • ApplicationUser
  • ApplicationUserManager

In my last project I had a library projectX.Core where I included the ApplicationUser within a folder called Entities, together with my other database entities. Everything in the MVC application got re-referenced to the correct ApplicationUser I merged the ApplicationDbContext with all the other entities. For me this had the following pro's:

  1. I could easily create relationships to the ApplicationUser class (and thus foreign key in db)
  2. I did not have to create separate migrations in two different projects.
  3. When creating an WebApi as well, referencing to the same ApplicationUser works perfectly (yet there is a duplicated ApplicationUserManager defined in MVC and API)

But it also had it con:

When throughout the application I want to know the current logged in user, I need the HttpContext which ends up in referencing HttpContext in about every library because HttpContext.Current is always null inside an class library (as far as I know).

Together with this comes in mind: session variables. For instance I need the current user's shopping cart, like, almost everywhere. (and it might be an anonymous user, so I need the session Id to query the DB)

The reason I ask is, because I have heard some people splitting it and I have seen an open source project ticketDesk that does exactly that. They implemented in such a way that all above listed classes are in a different project and a SecurityProvider is send to the Domain project library which is used to get the current logged in user. There never is a foreign key in the database to the TicketDeskUser from a Ticket, it relies on the application serving a good userId.

So what do you think is best? Keep authentication logic in MVC, put it into a separate library or combine it with the business logic? And how would you handle relationships between all entities if it is not the last choice?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.