We Keep Coding

Where do I place the entity framework queries in layered architecture?

I have .net core api project with following folders:
Models contains the database table classes and dbcontext
Services contain logic to send email, and business logic (example calculate student grade based on marks)
Controller contains the controllers with respective actions (api endpoints). The dbcontext is injected into the controller and the endpoints contain the LINQ queries (example: _ctx.Students.Where.....)
I want to organize this into layered architecture.
UI layer will contain the api project (controllers) and reference the business layer dll.
Business layer will contain the send email logic, and business logic (grading based on marks). I think this must reference the data layer to be able to fetch data.
Data layer will contain the table classes and db context.
Where do I place my entity framework queries which were previously in the controller action method?

I usually recommend people to use the repository pattern to structure Asp.net application in a monolithic fashion. At a high level, there are usually three-layer
Repository/Data Layer
Service/Business layer
Controller/API (Web Project)
In Repository Layer, we define all our models and database call(Your Entity framework will be here).
In the Service Layer, We perform all the business logic.
And in the web project, we define all the API endpoints and other client-side interaction services.
The followings are some of the articles related to the Repository pattern:
https://www.linkedin.com/pulse/repository-pattern-c-pawan-verma/
https://medium.com/net-core/repository-pattern-implementation-in-asp-net-core-21e01c6664d7
https://codewithmukesh.com/blog/repository-pattern-in-aspnet-core/
Some articles, here use the same project to define all the layers but you can simply separate all layers into a separate project (class library).

I usually layer my application like this:
APIs - EndPoints
Application Layer - All glueing code, mapping, orchestra code, utilities, and other application-level code comes here
Domain Layer - Purely contains domains, sub-domains, validations, interfaces for repositories and unit of work, and commands.
Data Layer - This layer contains the implementation of all the repositories and unit of work interfaces. And this is the layer where I keep all my queries and database-specific code.

Asp.Net MVC project with n-tier architecture

I want to asp.net mvc project using n-tier architecture. I have Confused in that issue;
I have 4 tiers that are BLL, DAL,Entities and WebUI. WebUI tier is a asp.net mvc project. I added data model into entities tier. In DAL, I create some classes about crud opparations using entity framework. Finally I serve this classes as repositories on BLL. BLL knows DAL and entities tiers, DAL knows entites tier and WebUI is only knows BLL. In WebUI, I can access repositories where is into BLL.
But this repositories' return values are entity classes. I have to give a reference from entities to WebUI tier. I don't want that WebUI accesses databese directly. It should access database using repositories inside BLL.
What should I do? I want to do right thing. Is anything wrong my
architecture?
Thanks for helping answers.

You can have another project that has only models for BLLEntities.
BLL will always have to map BLLEntities to DALEntities and DALEntities to BLLEnttiies.
You can use AutoMapper for that.
Any Layer above BLL should deal with BLL entities and not with DALEntities.

Move the Asp.net Identity 2 in another project

I am creating layered MVC Application that contains.
model layer: which is not using any reference for EF
Data Layer: which contains the infrastructure. (Repositories and unit of work ) and this layer referenced with Entity framework
Service layer
Web layer.
I am using Asp.net identity2. What I am doing is using ApplicationUser class in model layer and this leads me to reference model layer to Entity framework and Microsoft.AspNet.Identity.EntityFramework.
i am asking if there is a better way to do it, especially in feel that I am repeating my self while making both data layer and model layer using a reference to entity framework?

I don't think I completely understand your question but consider not mixing your identity model with your domain objects model:
ASP.NET Identity is a presentation layer logic and you have to consider if it's a good idea detaching it from your topmost layer (Web).
I would suggest you keep your Model or Domain project with Entity framework alone and avoid mixing it with objects that are directly related to presentation.
You can take a look at this post:
https://aarcoraci.wordpress.com/2017/02/15/asp-net-mvc5-entity-framework-repository-pattern-and-unit-of-work-revisited/

ASP .NET MVC Onion Architecture

I'm developing an application following this architecture:
Core project (Domain entities, Repositories interfaces)
Infrastructure project (Database operation, Repository implementation, EF)
Test project (Unit Test project)
Web project (MVC project)
From this tutorial:
http://www.c-sharpcorner.com/UploadFile/dhananjaycoder/step-by-step-implementing-onion-architecture-in-Asp-Net-mvc/
I want to decouple my project and follow a "standard architecture". I have a few question:
1) I want to add a bussines layer, should i add a project like SolutionName.Services?
2) If i add the business layer, I need to use dependency injection to call the repositories in the business layer?
2.1) If my CRUD operation does not need business logic, the service (business layer) should only call the method on the repository? (I have models with business logic and models without business logic)
3) In the project, I need to read files and process the data based on the needs of the user, this should go in the business layer?

Using the repository pattern, how do I reference my domain models without creating a leaky abstraction?

Setup
.NET, C#, WebAPI, Entity Framework using code-first migration
Summary
I am designing a .NET solution using the repository pattern. The repository sits at the bottom of my stack and currently contains my domain models. I have layers on top of the repository (e.g. BLL) and finally I have an API layer on the top of the stack which contains my RESTful API endpoints.
Here is a simplified pseudo-diagram of the current solution stack:
-API
-BLL
-REPOSITORY
Problem
In the API layer, I would like to use .NET's ModelState validation inside each of the controller's endpoints. Problem is, this requires that the API layer have a reference to (ergo knowledge of) the Repository layer. Wouldn't this be a leaky abstraction?
It seems like the use of Data Transfer Objects would be the solution, but this almost seems silly since they would be essentially identical to the Domain Models in the Repository. That doesn't allow for much abstraction.
An alternative?
I am kicking around the idea of adding a separate project to contain the Domain Models, and then allow the API, BLL, and Repository to all reference that project. Any reason this shouldn't be done?
The only downside I see here is that now three of the projects in my solution will need access to the database:
API (because I have set up OWIN authentication in the API)
Repository
DomainModels (because I am using code-first migration)
Any help is appreciated.

The repository sits at the bottom of my stack and currently contains my domain models
That's your problem, the repository uses domain entities, but it doesn't contain them. The repo is part of the persistence, your domain model should be part of the Domain layer. The repo interface is part of the Domain too.
ALso, you domain model should be different (as a concept) than you persistence model i.e the pocos you're using with EF to do CRUD stuff. The domain objects are modelled according to the business view, the persistence pocos are designed with db usage (store/easily queryable) in mind.
The domain layer should be at the core, persistence and application services should use it i.e depend on it. You can take a look at the onion architecture or business components/ vertical slices (which is a more advanced approach IMO)