Question Proper Folder Structure

[Mitchelln11]

This might be too broad of a topic, but how are you supposed to set up a file structure when using .NET Core MVC.

When creating a new project, you are given the following:

>>Dependencies
>>Properties
>>wwwroot
>>Areas
>>Controllers
>>Data
>>Models
>>Services
>>Views
>>appsettings.json
>>Program.cs
>>Startup.cs

Now, I've created a few projects, and gotten thing to work, only I feel like a professional will look at my folder structure and just be disgusted.
What I've gotten out of the whole MVC setup is:
Models: A place to set up records and fields, probably meant for a database
Controllers: Where all of the work happens
Views: The front end of an application that users actually see.

On projects, I've just been putting methods in my controllers wherever they are relevant
ie:
>>Controllers
>>>EmployeeController
>>>>Method to calculate hours worked against hourly rate

Sure, something will work, but is this just beginner programming? (Which I am)
Is that "Method to calculate hours worked against hourly rate" supposed to be in its own folder of Methods?
I've seen people create their own libraries for separate methods. Wouldn't that mean that the whole MVC setup doesn't follow clean architecture? Would that be why the newer .NET Core web app no longer comes with Controllers, Models, or Views (now Pages)?
What if there's a method that isn't specific to a single Model?

I feel lost as to structuring my web applications.

Does anybody have any good resources for architecture, or file structure?

Just asking as a curious beginner in programming.
Anything would help. Thanks.

 

[jmcilhinney]

Speaking in a very general sense, the Model is the data, the View is the UI and the Controller is the logic. In a more specific sense, the Controller should be the PRESENTATION logic and the Model should be the data specifically for the View. You should also have separate business logic, what is often referred to as a service layer, and also a separate data persistence layer, which is responsible for moving the data between the application and the database in both directions. The data might change shape several times between the database and the View. You might have entity classes, DTOs and view models for the same data in different layers. The service layer and the data layer could just be classes in dedicated folders in your web application project but it's probably better that they are in dedicated projects, as that's how they will be done in a professional-grade project and particularly when working in a team. Here's the Solution Explorer for a project that I've been part of at work for some time

Those projects are as follows:

Dto: lightweight classes that contain data for the purposes of moving it between the service layer and the web application
Global: types that are used in multiple other projects
Mapping: Uses AutoMapper to automatically map between EF entities and DTOs
Model: Entity Framework context
Service: Concrete types containing business logic
Service.Interface: Interfaces for unit-testing business logic
Service.Ioc: IoC (Inversion of Control) container for mapping service interfaces to concrete types
Service.Test: Service layer unit tests
Web: MVC application project
Web Tests: Application layer unit tests

 

[Mitchelln11]

Speaking in a very general sense, the Model is the data, the View is the UI and the Controller is the logic. In a more specific sense, the Controller should be the PRESENTATION logic and the Model should be the data specifically for the View. You should also have separate business logic, what is often referred to as a service layer, and also a separate data persistence layer, which is responsible for moving the data between the application and the database in both directions. The data might change shape several times between the database and the View. You might have entity classes, DTOs and view models for the same data in different layers. The service layer and the data layer could just be classes in dedicated folders in your web application project but it's probably better that they are in dedicated projects, as that's how they will be done in a professional-grade project and particularly when working in a team. Here's the Solution Explorer for a project that I've been part of at work for some time

View attachment 994

Those projects are as follows:

Dto: lightweight classes that contain data for the purposes of moving it between the service layer and the web application
Global: types that are used in multiple other projects
Mapping: Uses AutoMapper to automatically map between EF entities and DTOs
Model: Entity Framework context
Service: Concrete types containing business logic
Service.Interface: Interfaces for unit-testing business logic
Service.Ioc: IoC (Inversion of Control) container for mapping service interfaces to concrete types
Service.Test: Service layer unit tests
Web: MVC application project
Web Tests: Application layer unit tests

This is very helpful, thank you.
Is there a name for the way you are setting things up? I've come across Hexagonal Architecture, Onion Architecture, and Screaming Architecture.

Also, is this default MVC folder structure kind of outdated?

 

[Skydiver]

That default MVC structure that gets created is geared for a quick standalone project for a relatively small team and is what seems to be favored nowawadays. The setup above with the multiple projects is the older N-tier approach that used to be very popular, and the though of having each major component in its own project was that a separate assembly could be generated and shared with other web applications for re-use. I think that the change over to the single project is partially a realization that each web application actually turns out to be pretty tightly coupled within itself and that there is very little sharing between different web applications.

There is a major advantage to the multiple library/N-tier approach above. It allows for more targeted unit testing. You don't have run everybody else's unit tests if you don't want to.

 

[jmcilhinney]

One reason we do it that way is that it allows the service layer to be referenced by a web site (MVC) or a web service (Web API). If you build everything into the web site and then you need to have the web site interact with a web service instead, you need to pull all the service and data access code out and move it. With MVC and Web API being so similar, that's not actually too difficult, but it's still a waste of time. That said, once you make a decision to go one way or the other, it's probably rare that you actually would have to change. Just once is too often though.