What is the most appropriate approach to the creation of the ViewModel?

Dear users,

Comprehend the delights of the framework ASP.NET MVC together with Entity Framework. Use DataBase-First approach design.

Entity Framework automatically generates models for me, each model is described in the partial class(perhaps not so simple?).

Question following: there is a simple model of car ordering - Order. Let's simplify this entity of two properties:
The brand of a car(Car)
-Customer name(CustomerName)

Get the generated class:

public partial class Order
{
 [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA2214:DoNotCallOverridableMethodsInConstructors")]

 public string CustomerName { get; set; }
 public string Car{ get; set; }
}


With this model, assume bound 3 View:
ListView-Displays all orders
-ItemView - Display a specific order
-CreateView - Add new order

For each View I create a separate ViewModel(let's say I have each View contains a control panel which may contain their function).
The ListView contains a Create action,
ItemView - Edit, Delete,
CreateView is Save, Cancel

In the case of ItemViewModel model has the following form:

public class OrderItemViewModel
{
 public ItemToolboxViewModel Toolbox { get; set; }
 public Data.Order Item { get; set; } // this is a reference to the domain model
 }


In the case of the latter CreateViewModel, I feel that I need to give the user to select the brand, i.e. to implement DropDownFor to the input which you want to file for the List<selectlistitem></selectlistitem>. In this case, the model has the form:

public class OrderItemCreateViewModel
{
 public ItemCreateToolboxViewModel Toolbox { get; set; }
 public OrderItemCreateModel Item { get; set; }
}

 public class OrderItemCreateModel 
{
 public string CustomerName { get; set; }
 public string Car{ get; set; } // used for binding values in the View
 public List<selectlistitem> Cars{ get; set; } // used to populate the list of cars in the DropDownFor
 }</selectlistitem>

Respectively receiving POST-request OrderItemCreateViewModel.Item I can send it in to Context.Orders.Add(). You have to define a new object domain model Order and to initialize values of properties of OrderItemCreateViewModel.Item
July 2nd 19 at 18:22
3 answers
July 2nd 19 at 18:24
Solution
I guess I don't quite understand something... the ViewModel represent models that will go into the view to display the information. Why one ViewModel to encapsulate another? These models mostly contain only the necessary info for the view and no logic. If the domain model lists cars do not need, it is not worth them there to do. You need to initialize ViewModel the desired list and this model to give wiske. ViewModel is initialized either manually by a domain model, or Atomprom.
Thank you. Can I ask you one question arising?

I have an action Create in the controller. I can make a POST request in various ways ranging from request.form ending models. As I understand it is recommended to operate the models. Besides, I have already connected with View. I got to the login ViewModel. How do I optimally implement CRUD operations?

Used Entity Framework which is already implementeret Repository Pattern, right? Given the fact, I have a simple data layer(using a single source database), I conclude that none of the repository by the context, formed by the EF-om, I don't implementary. Each available I have a DbSet is already a kind of repository, right?

I accordingly to the input Context.Add() need to pass the domain model. In the controller I received ViewModel. Whether the instantiation of the object domain model, followed initializes properties of the resulting ViewModel best option? - Lera.Durgan8 commented on July 2nd 19 at 18:27
Again, do not quite understand)) Entity does not implement the repository it is a database table MapIT in the objects with which it is convenient to work in the code. If You want to implement the principle of CRUD, then implement it separately, where the entrance will give your dbContext. Your can implement CRUD using the Repository pattern. The controller is already working with the data through the repository. If you want more abstraction, you can highlight another layer of service, which will work with the data through the repository, and the controller will know only about service and not about the many repositories of entities. All these things are very well described in classic resources .net metanit.com/sharp/mvc.php - Abner32 commented on July 2nd 19 at 18:30
: Well, I won't go into the topic relished whether EF repository or not. Generally very similar because derived DbContext is a UoW analogy, and each DbSet through which I can implement CRUD, is the analogy of the repository.

Drew conclusions based on these resources:

softwareengineering.stackexchange.com/questions/18...

https://www.asp.net/mvc/overview/older-versions/ge...

The question is what it is. I got a POST-request in the controller the ViewModel. Then here I instancetwo domain object and initialize its values from the ViewModel. Next, call the dbContext.Orders.Add(model) where model-initialized my object. Is it OK approach? - Lera.Durgan8 commented on July 2nd 19 at 18:33
The CRUD which is on the dbContext directly in the controllers used in small test samples. The option that You described, Yes, in the examples, or prototypes do, Yes, the entity in fact implements the UoW. In real projects, wrap your dbContext in the repository and on top of another can make your UoW. This is done for greater flexibility and the ability to write unit tests for those controllers. If I put the dbContext in the controller, then You will only need integration testing. If You need to form some kind of model of the more complex selections, You'll be doing in the controller? That's why it take out in a separate service, as I said directly with dbContext only work in your own repository, then the repository is wrapped in its own UoW or some sort IDataManager, then the dataManager of injectate to the controller through the constructor. And it turns out that in the constructor, using this wrap are already working with the data. But most of this dataManager injected in another selected layer IService, and the service given to the constructor.

In General, in Your option do, but not in real projects. Because it turns out the hard connectivity entity with the controller. - Abner32 commented on July 2nd 19 at 18:36
July 2nd 19 at 18:26
No, because it's an MVC framework.
Oh? You view function immediately sent a domain model? - Lera.Durgan8 commented on July 2nd 19 at 18:29
: Yes, Controller is doing. - Abner32 commented on July 2nd 19 at 18:32
The controller deals with the fact that exchanges with users view models, and interacts with the service (which contains business logic code), forming from them the domain/DTO model.

You have been a confusion due to MVC in the name of the framework. But if you look at a typical web application globalno, the web face (ASP.NET MVC ASP.NET Web API projects) - this is just the View layer, so the internal model is a separate view-models that are formed for the convenience of working with strongly typed views, and do not go beyond the scope of this project. - Lera.Durgan8 commented on July 2nd 19 at 18:35
: The fact that they do not generate, but to work directly, so that it is only the model type Pure Old C# Object (like POJO in Java) and performance, so it is not the ViewModel, and the MVC is not MVVM. - Abner32 commented on July 2nd 19 at 18:38
: It is possible, especially if you love to smear your domain model is unnecessary attributes and to use ViewBag in all fields. To view the model, you can imagine how "model of the presentation layer". But they are called "View models". And it's not about MVVM. - Elna.Volkman92 commented on July 2nd 19 at 18:41
July 2nd 19 at 18:28
I think you need to add reference of car models and create a relationship one-to-many, like this...
public partial class Order
{
 public string CustomerName { get; set; }

 CarLabelId public id { get; set; }
 public CarLabel CarLabel { get; set; }
}
public class CarLabel
{
 public int Id { get; set; }
 public string NameCar { get; set; }
}

Sincerely, R. Zhidkov
My inaccuracy in the description of the issue.
The Car entity is already defined, the relationship between an Order and the Car was initialized at the design stage of the database.

Accordingly, the Entity Framework I have generated in the model Order
a virtual property public virtual Car Car { get; set; }

I have this issue, I think, more confusing.

The point is that when you create OrderItemViewModel I make a reference to the Data.Order
When creating a OrderCreateViewModel I wrote an additional model to store List for cars.

The question is that whether it is optimal to expand the domain model partial class Order by placing the additional field List for cars? - Lera.Durgan8 commented on July 2nd 19 at 18:31
: The model is not distorted in the view via ViewBag SelectList give, in your case, so
foreach (var i in _context.CarLabel.OrderBy(n => n.Name))
{
 ViewBag.CarLabel.Add(new SelectListItem() { Text = i.Name, Value = i.Id.ToString() });
}

Vyuha;
@Html.DropDownList("CarLabel", null, htmlAttributes: new { @class = "form-control" })

For submitu catch the ID in controller:
int CarLabel - Abner32 commented on July 2nd 19 at 18:34

Find more questions by tags ASP.NETEntity FrameworkC#