Develop Reference

Identity in ASP.NET Core (2.1): Why do we need to add a new Context to customize IdentityUser?

EDIT: I should probably add that in my project (which was based on the ASP.NET Core 2.1 - WebApp with MVC, with "Individual User Accounts), I don't have "AppUser" (or an equivalent class that inherits from IdentityUser), and ApplicationDbContext inherits from IdentityDbContext - not from IdentityDbContext (or IdentityDbContext).
I'm currently learning / starting with ASP.NET Core and use "Add New Scaffolding Item" to Add Custom user data to Identity and noticed that I cannot use the existing context (ApplicationDbContext) if I want the scaffolder to create my custom user class. The only way to have that field enabled is if I add a new context, which will also add a new connection string. But the new context seems to be essentially doing the same that my already existing context does.
I also noticed that the two new classes (AppExtendedContext and AppExtendedUser in my case) were put under Areas/Identity/Data, while I'd actually expect them to be under Data and Models.
So I was wondering: Why? ;-)
Or, to put it in more actionable terms: Would it be safe to refactor the generated code back to only use a single ApplicationDbContext? What would I be losing / what kind of trouble would I get myself into?
The answer could be as simple as "for pragmatic reasons" (e.g. because it makes the automatic code generation easier / safer); and in that case, moving these things around should be fairly safe as long as I'm not going to use the scaffolder again. But then again, it might make life more difficult/confusing when upgrading (e.g. to ASP.NET Core 2.2, or ASP.NET Core 3.0).

Just trash your AppExtendedContext and AppExtendedUser classes and use the ApplicationDbContext and AppUser and add your customizations there.
They are ready for modification (they inherit from IdentityDbContext<TUser> and IdentityUser<TKey> respectively. Feel free to rename them to something more familiar to your application (such as Customer or CustomerUser), if you don't like the AppUser name.
There's really no need to inherit from AppUser or ApplicationDbContext, they are the final/concrete classes for your Core Identity.

Make sure your context inherits from IdentityDbContext<>. You have to specify the type to use for your application user, which you can just create as a class that extends IdentityUser (given the fact you want to start extending the IdentityUser class). Go for something like YourCustomContextType : IdentityDbContext<YourCustomUserType>.
As for the Identity services registration you need to specify your class there too using AddDefaultIdentity<YourCustomUserType>().AddEntityFrameworkStores<YourCustomContextType>().
Make sure you also look at how other people approach extending the Identity functionality:
How to extend available properties of User.Identity

Use same local database in independent projects

I have a solution with several projects:
A class library that just contains the database
context, lets call it DatumClassLibrary.
A class library that contains model entities, lets call
it ModelsClassLibray
A class library that contains repositories for the model
entities of ModelsClassLibray, lets call it RepositoriesClassLibrary.
Besides that I have to other projects, one is an MVC5 application and the other is a WebApi application.
How can I use the same local db file both from the MVC5 application and the WebApi application, using entity framework code first?

EF doesn't care how/where you use it...
Just pass the correct connection string in the Context's constructor every time you use it

Implementing your own UserManager, UserStore without Entity Framework

I'm looking for any insight and/or links for how to implement my own login/registration system for a MVC project. IS it worth using UserManager and UserStore? When you create a new MVC application it relies on Entity framework, thus I'm wondering if it's worth creating my own login/registration process or to use UserManager and UserStore but no longer rely on Entity? Additionally would it perhaps be easier to rely on Entity for that stage of the registration/loging in but create my own table/retrieval methods independent of entity?
To sum up:
1) Should i switch from Entity to use UserManager/UserStore
2) Create my own custom create/manage account controller /models
3) Hybrid it up where I used Entity for logging in / registration and then having my own additional table for additional data just keeping bare data on the entity manage Table.
Thanks!

ASP.NET MVC Database Access Layer

Since I am new to MVC I have a few questions about the database connection.
I am trying to build an MVC application, and so far I have built 2 layers: Model(where my classes are, without any functionality) and Business (there is the functionality for my classes, every class has its own Business class) and there is also my MVC application. Both these layers are separated from the MVC project, I use them as ".dll-s". I am also using the repository pattern and the dependency injection is done by Unity.
Now comes the tricky part (or at least it is for me). I want to bind my application to a database. Most of the tutorials I have found rely on Entity Framework, but I don't want to use it, I want to use ADO.NET (Entity Framework makes me feel like I am giving my "power" away, so I want to manage the SQL on my own). So what is the best way to do it? How can I access the Web.Config from outside and read the connection string (or should I take care of the connection string inside the data access layer)? Is there any best practice how to manage the connection from "outside"? I mean I could easily just create a dbaccess object inside my MVC application, but I don't want that. In the MVC application I just want to use my business(object) classes.
And one more thing. What is the best practice for DataAccess: to build a new layer, or is it also fine to include the functionality inside my business layer? I am more tending to build a third layer, so I can reuse this code for any other application but maybe there are some other approaches.

You can create another project called "DAL" to handle your data access layer which is built using pure ADO.NET. You will add a reference to the entity project so that you can return these entities from your Data access methods. Now from your Business Layer, Add reference to the Data Access projects so that you can access these data access methods from the Business layer classes. From your MVC project, Add reference to your Business project ( and entities project if you are using those entity objects in your MVC project). In this way your MVC project do not have any idea what data access technology you are using.
You do not need to have connection string in your DAL project, Keep that in your UI MVC project and your DAL project will be able to read it as long as you have the proper references added between these projects.

Where to put Business Logic classes in an Entity Framework - ASP.NET MVC 4 Solution?

I have a Solution with one project is Entity Framework and have my ASP MVC project, I looking for some advice or opinion about the idea of create in top of my POCO objects and the DBContext, a Business Logic Layer with static classes that have the all the methods (example a ContactBLL class with GetContactByID, GetAllContacts, GetContactsByType) to allow the access to the model data and that can be accessed in the Controllers Actions. In that way I don't have to put the implementation code of this methods in Controller Actions methods, and it can be reusable invoking this methods in other Action Controllers. I will appreciate your opinion because it could guide me to respond a question I've asking to myself around a week based in the answer to this one (about where to define the DBContext and how use it).

You can create different projects according to core functionality.
Data Access Layer(DB context and repository etc.) you can make Project.DataAccess, it will have only db context class and repository.
Business Logic Layer(Project.Business) it will have business logic and make call to data access layer.
UI Layer(Project.WebUi) it is mvc project.
and so on.
for detail info you can see this http://prodinner.codeplex.com/ code

Create separate class library for your POCO,
then create another class library for your repository, this should
include only the interfaces needed for your repository
and the implementation will be on another class lib like Project.EF,
Project.NH which will include Entity Mapping, Migration, Repository
implementations. but in reality, chances are you wont be changing
your ORM lib once it was implemented because it will just cause you
a lot of headache(just my 2cents).
you'll create your business layer(class lib) and
web project as separate lib. Models folder of your MVC project will contain your ViewModels.
this is what Im using right now and of course not the best structure, it just something that Im happy with :). hope it helps.

In general, there are four standard projects in a ASP.NET MVC - Entity Framework solution. They are 1) MVC, 2) Core/Business Logic Layer(BLL), 3) Data Access Layer/DBContext (DAL) and 4) Common/Utility.
Standard MVC project consists three main elements which are Model, View and Controller. However, middle to complex solution usually cuts off the Model element from MVC project and moves it back to BLL, we call it as ViewModel(POCO). Following this structure, MVC project is now responsible for employ/use the services from BLL and control the UI through controller.
Business Logic Layer (BLL) is the core of implementing business logic. It is responsible for serving request from the MVC project and work with DAL to persist data. As said above, BLL is the place to define ViewModel, its relations as well interface/ abstract class to support implementing design pattern. Viewmodel(POCO) is likely mapping one-one to data entity at DAL but we do not use the data entity directly on View. Following this structure will help to increase the customization on ViewModel like adding constrains
DAL is the place for DBContext and its data entities.
Common project consist of shared functions like Logging which is used in 1) 2) and 3)
Please read more at
https://www.codeproject.com/Articles/70061/Architecture-Guide-ASP-NET-MVC-Framework-N-tier-En
https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/