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.

Scaffolding DB Context from existing database in layered architecture

I have an existing database which I am using in a CRM project developed in asp.net MVC project. Now our company has decided to develop HRM system also using the same database. The business requirement is to use Clean Architecture with .net core 3.1 as a backend for HRM. The project is structured in a way that it has four layers.
Presentation Layer: Contains Controllers and Web API endpoints.
Application Layer: Contains Application wise logic and types.
Business Layer: Contains Enterprise wise logic and types.
Infrastructure Layer: Contains all the cross-cutting concerns.
Presentation Layer and Infrastructure Layer are dependent on Application Layer and Application Layer is dependent on Business Layer. The business layer is independent of every other layer.
I have to scaffold the DB Context and Entities from the existing database so that Entities will go to the business layer and DB Context will go to the Infrastructure layer (Note: Infrastructure is not dependent on Business). How can I do that? Is there anyone who has done this earlier? Any help would be greatly appreciated.

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.

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)

Domain Layer + Repository Layer with asp.net mvc question

Just a quick question about my Domain Layer/ Domain Service... Should I allow this layer to have read only access to the database? i.e. hook up a IReadOnlySession and only allow the Repository Layer to have access to CRUD i.e. Persistence? Or should the Repository Layer do both the ReadOnly and CRUD with the service layer making a call to the Repository layer?
One thing I find rather strange is why most of the time the Service Layer is only making a direct call to the Repo, hence the question - move out ReadOnly to the Domain Service Layer.
EDIT:
I have decided to have 3 layers in my app (for anyone who is interested in what I have done), the first layer is the WebUI (I will have 3 in total, business requiement), below this is the Domain Service i.e. All business rules, validation, checking if user can do action x, user is valid user, calling the repo for the data. The final layer is the Repository Layer i.e. the layer that talks to the database iteself, I am using LinqToSql, all my CRUD and ReadOnly logic resides here. As a side note I created another project called Model, this is the actual LinqToSql model entities i.e. Product, Item, Shop, Customer etc. This very project is referenced by the UI, Domain Service and Repo, saving me from writing DTO, and from unecessary complexity hopefully.

In your application, only one 'layer' should talk to the database.
In the Repository pattern, it's the Repository.
It doesn't matter if it's CRUD or ReadOnly, it should go through the repository to the database.

I see the discussion as what are the responsibilities of these layers. The repository is clearly to provide an abstraction over the db. Done correctly and the users of the repository cannot tell if you are using SQL server, mysql or files for persistence. This layer must have all the necessary crud operations.
The service layer is another abstraction. It may depend upon the repository for persistence. There is usually a bit more business logic. Maybe cross repository concerns or another stream of data (gps for instance).
Some apps don't need a service layer. Don't add it until you need it. If you do have the need for the service layer, letting it be a thin rapper around the repo exposing read/write allows your models to only have one direct dependency.