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:
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:
- I could easily create relationships to the
ApplicationUserclass (and thus foreign key in db)
- I did not have to create separate migrations in two different projects.
- When creating an WebApi as well, referencing to the same
ApplicationUserworks perfectly (yet there is a duplicated
ApplicationUserManagerdefined 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?