"Does the concept still exist?" "Can I use the same approach?"
Yes, the ViewModel concept is still applicable in .NET Core and you would still use them as before, i.e. to assemble a selection of data into a 'shape' that matches the needs of a particular view.
"I can't find any information about this topic in ASP.NET Core MVC"
The official documentation discusses view models extensively. The Overview of ASP.NET Core MVC section has this to say:
Model Responsibilities
The Model in an MVC application represents the state of the
application and any business logic or operations that should be
performed by it. Business logic should be encapsulated in the model,
along with any implementation logic for persisting the state of the
application. Strongly-typed views will typically use ViewModel types
specifically designed to contain the data to display on that view; the
controller will create and populate these ViewModel instances from the
model.
In the Rendering HTML with views section:
You can pass data to views using several mechanisms. The most robust
approach is to specify a model type in the view (commonly referred to
as a viewmodel, to distinguish it from business domain model types),
and then pass an instance of this type to the view from the action. We
recommend you use a model or view model to pass data to a view.
The MVC/Advanced/Application Parts section also discusses View Models, the sample code there shows how you can assemble a number of different objects together for consumption by the view with a view model.
They also mention them in the section on Partial Views. There is some sample code that goes along with that here, but those examples don't actually really highlight the difference between a model and a view model.
A search through the docs as follows highlights some more too: https://learn.microsoft.com/en-us/search/index?search=viewmodel&scope=ASP.NET+Core
"..i want to make a dashboard for projects"
In your case the data you've provided just shows a single domain object (the 'Project') which has some child objects. If that's all the data you want to show then you probably don't need a view model as it would simply be a mirror of your Project model.
However, if you want to show other info on the Project dashboard, e.g. some data aggregated data about the number of projects in progress, a list of which projects are behind etc. then you might assemble a view model with properties for: Project, NumberInProgressPrjects, OverdueProjectsList etc.
public class ProjectDashboardViewModel
{
public Project Project { get; set; }
public int NumberInProgressProjects { get; set; }
public ICollection<OverdueProjectInfo> OverdueProjectsList { get; set; }
}
That's just an example, the point is you can use the view model to encapsulate all of the data needed by your view, rather than your controller returning a model object that matches a single domain object (often a table from your database) and then lots of additional data that's needed to make the rest of the page function in the ViewData collection (e.g. the data needed to populate the drop down lists). There are many excellent articles on view models, this previous question covers them exhaustively for example, and is just as relevant in .NET MVC Core as other versions of MVC.
"..where i need to put them?"
You can put them where you choose, just make sure you use a using statement if needed. The typical convention in smaller projects is to put them in a folder called 'ViewModels'.
