What's wrong with ASP.NET Identity in Onion architecture?

Question

ASP.NET

Decided it was time for me to try cool things like the Onion Repository+UnitOfWork architecture but I quite liked ASP.NET Identity which I would like to combine with this application architecture. I did not like the examples that were found on the net. For example , metanit.com/sharp/mvc5/23.10.php here the architecture of the layers is completely broken, namely:
- in the BLL the layer is connected to EntityFramework + Identity.EntityFramework
- in the DAL layer there is a bunch of business logic in the form of ApplicationRoleManager and ApplicationUserManager
and so on ...
Therefore, it was decided to make your own bike. To begin with, I took as an example a project that is generated when creating ASP.NET MVC with Identity already included and decided to repeat its functionality while spreading it into 3 layers.
Here's what happened:
https://github.com/dmitrievMV/OnionArchitectureWit...
In DAL:
- Entities.
- EF context
- Repository+UnitOfWork
- UserStore
All implementations in the assembly are private except UnitOfWork and UserStore. UserStore takes a UOW constructor and works with repositories. Only interfaces look outside. The structure of the database completely repeats the example from the small ones, except that the main keys are int.
In BLL:
-ApplicationUserManager
In WEB
-ApplicationSignInManager
Actually please help, spend a little time, just inspect the code. Answer a couple of questions:
-Have I implemented the Repository + UnitOfWork
correctly -Is the Dispose implemented correctly
-Which layer do you think ApplicationSignInManager should be in, because it uses OWIN and works with ApplicationUserManager
-Due to the fact that no layer except DAL knows about the database and orm, I decided to make connectionString a constant, is this a normal approach?
-Does it make sense to move the entities into a separate project and separate them from the annotations for the database?
-In the example, in the owin context, they put the ef context in this way app.CreatePerOwinContext(ApplicationDbContext.Create); how justified is this and is it worth it?
-In the implementation of UserStore for EF, they behave very strangely with dispose and I have a feeling that some data hangs in memory all the time, is that so?
How justified is such a bike?

Answer 1

Good afternoon!
Well, as far as I know, there are many implementations of UnitOfWork + Repository, and each of them has its own advantages and disadvantages. At you everything looks rather efficient and unit-testable.
I guess, yes. Only here private fields are private for that, in order to encapsulate them. I consider it very wrong that your disposed variable has a public modifier. I also saw somewhere on the net that it is recommended to explicitly assign null to the db variable after calling db.Dispose():

if (_db != null)
{
    _db.Dispose();
    _db = null;
}

I don’t want to seem intrusive or develop the topic of a holivar, but naming a private field through the “_” symbol at the beginning of the name, in my opinion, is still more convenient. Those. instead of private DbContext db , it's better to write private DbContext _db . It seems to me that visually such code is easier for other people to read.
Depends on the complexity of your application. It may be that there are several MVC applications, but they must use the same authorization / authentication mechanism. Then the ApplicationSignInManager component can be moved to a separate project. If there is no such need, then, in my opinion, you can safely leave it in the client (MVC-app).
No. DB connection strings are best stored as configuration parameters. For ASP.NET 5 - in web.config, for example. For ASP.NET Core - for example, in the appsettings.json file.
Definitely. Because your entities represent a domain model. Separating them into a separate project will make your architecture more modular, and therefore, you will be able to hack this project only where it is needed, without dragging with you all sorts of DbContexts, Repository, UnitOfWorks, etc.
In the example, in the owin context, the ef context is inserted like this app.CreatePerOwinContext(ApplicationDbContext.Create); how justified is this and is it worth it?
In the implementation of UserStore for EF, they behave very strangely with dispose and I have a feeling that some data hangs in memory all the time, is that so?
I won't suggest here. I would also be glad to hear a competent opinion.
What kind of bike? :) If you have your own implementation of any ***Store, then I think yes, because otherwise it will not work to untie them and place them in different layers (I myself suffered from this issue, and as a result, having spent a ton of time, I followed the advice to make my own implementations *** Store to make the architecture more modular and easier to unit test).
At one time, this series of articles (of 4 parts) helped me a lot: techbrij.com/generic-repository-unit-of-work-entit...