Develop Reference

What is the name of the architecture and the purpose of using dbcontext in a service rather than a controller?

I have multiple API controllers that have GET/POST functions which require database access (read/write). So I have created the dbcontext and injected it into every controller via constructor injection. Then within the GET/POST functions, I am using Entity Framework querying syntax like:
_context.TableName.Where...Select...ToListAsync()
I have been asked to review this and rather than injecting the dbcontext, make a service out of it and inject the service into the controller.
Am I correct to understand that this means the service will have functions (like GetData(), InsertData(val)). Within this service functions will be the entity framework querying that is interacting with the database. I must then inject the service into the controller so that when the functions GET/POST want to interact with the database they make use of the service functions. I believe this is so as to separate the Entity Framework query syntax and place it into service class rather than the controller.
What is such an architecture called?

Its called repository pattern/layered architecture.

It is called Repository pattern, by extracting database logic in service/repository you are making it more readable.
Ideally you api layer should only worry about following points
api endpoints
versioning
general exception handling
authentication and authorization
Database or business logic should be in separate layer, this layer handles all business logic and database access.
If you want to go deeper you could also separate business layer and database layer too, So your api will forward request to Business layer and business layer will perform required business logic, for database access Business logic will call Database layer for data. Main advantage of this approach is that if you want to change database provider you will only need to modify Database layer, this approach is called 3 Layer architecture.
** EDIT **
Here is example web app with .net 5 Api and angular 12 with Sql server

"layered architecture" separate business layer and database layer from presentation also known as n-tier architecture.
Most commonly 3 Layer architecture;
https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
What you call these 3 layers seems to vary a lot!
but in a nutshell
Frontend / UI/ Presentation /Architecture layer*(DDD)
Logic / Service layer / Business layer /Domain layer*(DDD)
Backend/Data layer/Repository layer*/ Infrastructure*(DDD)
the * just means there's more to the story

DDD architecture

i have a this question, that i just cant get my head around it
Right now, i am implementing a DDD architecture, in a .NET CORE project, i have created 3 layers,
Application, Domain, Infrastructure, but there is a problem, on which i cant understand
I have implemented the Repository Patterns and IUnitOfWork, but a question remains in my head
The domain layer will do the business logic to the Data, but how is that Data going to be persisted in the DB? since the Domain layer cant have dependencies on infrastructure
Will it send the data back to the Application and then Application layer sends to the infrastructure? Or will the Domain layer have a ApplicationDbContext file too, like Infrastructure Layer?
Here is a snippet of my Current Folder structure!:

Domain Layer usually contains enterprise logic and entities. Application Layer would have Interfaces and types. The main difference is that The Domain Layer will have the types that are common to the entire enterprise, hence can be shared across other solutions as well. But the Application Layer has Application-specific types and interfaces.
The Core Layers (Domain and Application) will never depend on any other layer. Therefore we create interfaces in the Application Layer and these interfaces get implemented in the external layers. This is also known as the Dependency Inversion Principle.
The Infrastructure Layer is where you would want to add your Infrastructure. Infrastructure can be anything. Maybe an Entity Framework Core Layer for Accessing the DB including DB Contexts and Identity and etc. Most of the project's dependencies on external resources should be implemented in classes defined in the Infrastructure project. These classes should implement interfaces defined in the Application layer.
The Application layer has a dependency on the Domain layer and the Infrastructure layer has a dependency on both Application and Domain layers. In my approach which I usually apply CQRS pattern, I implement the handlers of my queries and commands in the Application layer.
In order to get a better understanding of this matter, I recommend you to study Clean Architecture articles on the web.

MVC 3 Repository Pattern via SOAP

appreciate any help with this.
We are currently working on remodelling a legacy project that is now heading towards being too much of a nightmare to maintain. So, we've decided to properly normalise the data structure and use Entity Framework 4 Code First development in an MVC 3 project using a repository pattern. The issue we face at the moment is that the legacy application is hosted on a server outside of our main infrastructure for security reasons - therefore all CRUD operations are done via web services, there is no direct connection string to the MS SQL database.
My "proposed" solution is to define my repository contracts, during development there will be a direct connection to the database but once deployed there won't be (there may be scope to getting that changed later). So, would it be reasonable for me to provide two concrete versions of the repository working to the same contract. One that uses LINQ to perform CRUD operations (development and possible the infrastructure we can move to later) and another version that uses SOAP to pass objects (that would mean my POCOs would need to be defined as Serializable) and perform the CRUD operations this way?
Does this sound feasible or is there a much better way of achieving this?
Thanks!

If you are responsible for developing both client and service part you can use some simple approach:
Use some shared interface for repository and service client
When working with remote repository in client inject service client - the service will use repository implementation directly
When working with local repository in client inject repository directly
By using this approach you will have single repository implementation for both scenarios and your upper level logic will not change. There will be only additional web service layer for remote repository. Your repository will have to encapsulate all data access logic and queries = no linq queries outside of the repository which is not the issue in your architecture because linq queries are not serializable without your own custom development or without using WCF Data Services (but it would have other impacts on your architecture).
Btw. it is not very common to place repository behind the web service. More common is to place whole service layre / business logic behind the web service.

Entity Data Framework and Web app architecture

I Am creating a web application and first use Entity Framework. I created Entity Data Model and now I am not sure, how to proceed now.
Premise: My database is really simple (Rating, WebPage, Visitor) and database tables corresponds to the business objects.
My suggestion is 3tier architecture but how to make it?
It is good idea create partial classes with the same name as Entity Framework objects (Rating, Visitor) and declare here new methods (GetAverageRating()...)? Or is better create some VisitorProvider, RatingProvider and place logic here?
It is better use EF objects in BLL and Presentation Layer or I should create my own BO objects on my BLL layer and transform EF object to BO?
I'm think, it is more practical use static methods on my DAL than instantiate classes on BLL. Do you agree?
Can you recommend me some best practices? I have many ideas how to create it, but I do not know what is the right.

3 layer architecture is quite popular but what it really means?
Presentation layer
Application layer
Database layer
If you ask what each layer means you can be pretty sure you will get several different answers. You can further divide each layer into sublayer and build layered hell like:
Client side presentation layer
Server side view layer
Controller layer
Service facade layer
Service layer
Domain objects layer
Repository + Factory layer
ORM layer
Stored procedure layer
Database view layer
Database table layer
WTF? That is just example that application can be easily over architected. It can go even worse if you insist that only neighbours can exchange data and if you decide to add special type of objects to be exchanged between layers instead of flowing sing set of objects through multiple layers.
Add layers which you need to make you more comfortable with developing the application and which will do reasonable separation of concerns and maintainability needed for the scale of your application. You can simply do the most simplest application which will be used just few weeks and must be developed as fast as possible. In such case you can do that within few days simply by using ASP.NET web forms and data source controls (or ASP.NET dynamic data). It can be badly extensible but in such situation it is exactly what you need to implement application quickly. Writing layers and doing all the stuff around maintainability and extensibility is reasonable if you need it. Another quick prototyping technique is ASP.NET MVC Scaffolding which can create quick multilayered skeleton of the application which can be further modified.
Both approaches are correct and it only depends on the approach you like. The first is called active record pattern but it is not used very often with entity framework. The second approach is more popular. You can either use EF directly in some middle class which you called Provider (common name is also Service). This class will do both data access logic and business logic. In more complex applications developers like to somehow wrap EF to separate class following repository pattern and call the repository either from service or directly from web app. code behind or controller (depending on amount of business logic). Try to do it without repository first. My personal opinion is that people should start to use repository only once they understand EF itself.
Again both approaches are correct. In a simple application it is fully acceptable to create EF model with POCO classes (EFv4.x) and use them in all layers. If you are using ASP.NET MVC you can find that you need special classes as view models to fully represent needs of your individual views. In a more complex application you can have separate objects exposed from a business layer - this is especially used if the business layer is exposed as a remote service (WCF).
It depends how you write these DAL methods - it is absolutely necessary to not share the EF context among requests! It also depends if you want to write some test or not. Layer defined by static methods is something which goes directly against testable architecture where you want unit test just single layer (unit testing with EF can be hard). It also depends if you want to use dependency injection which is based on instances.

What is a good or best in your opinion way to do OOP in C# ASP.net

I have been working on coming up with the best wy to put the classes for the best OOP. Sometimes I wonder if I am trying to over kill the thought process.
I am thinking now to have as an examples the Categories Object
Files
Cateogories.cs - Object File
CateogoriesDAL.cs - Data Access Layer
CateogoriesBLL.cs - Business Logic Layer
CateogoriesWS.cs - Web Service
When you call form any application local or external you would call the web service and it would get what you need.
Examples:
You would create a Categories Object so you could pass it to the Web Service Layer when you wanted to Save (Insert or Update) a Category. All of the business rules would be in the Business Logic Layer.
How do you implement the OOP?

You might want to look into using an Object/Relational-Mapper (ORM) such as Entity Framework or NHibernate to simplify things. You could then use a simple domain driven approach with Repositories, Services etc.
EDIT: The repositories are responsible for the actual interaction with the data layer; Get/Save entities. Then you could use Domain Services for actual "business logic".