Это будет длинный вопрос, но, к слову, я все еще не могу понять, почему именно BETTER использует View Model вместо Model при работе с CRUD-действиями
Это то, что я узнал до сих пор, пожалуйста, поправьте меня на этом пути. Поэтому, пытаясь реализовать метод действия "Создать", "лучше всего" сделать следующее (я сначала использую код фреймворка сущности):
DAL
БЛЛ (контроллер)
Например, при создании действий контроллера вы можете:
public ActionResult Create()
{
return View();
}
//
// POST: /CRUD/Create
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(Employee employee) ---- Using actual entities
{
if (ModelState.IsValid)
{
repository.Add(employee);
return RedirectToAction("Index");
}
return View(employee);
}
В виду вы делаете:
@model foo.Entities.Employee
Или:
public ActionResult Create()
{
var model = new EmployeeViewModel();
return View(model);
}
//
// POST: /CRUD/Create
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(EmployeeViewModel model) ---- Using viewmodel
{
if (ModelState.IsValid)
{
//map here or use automapper
var employee = new Employee()
employee.Name = model.Name;
repository.Add(employee);
return RedirectToAction("Index");
}
return View(employee);
}
В связи с этим вы делаете это:
@model foo.Model.EmployeeViewModel
В чем же разница? зачем использовать View Model с большим количеством кода?
а также я пытаюсь реализовать действие контроллера обновлений с помощью модели представления:
public ActionResult Edit(int jobId)
{
Job job = repository.FindJob(jobId);
if (job == null)
{
return HttpNotFound();
}
var model = new JobEditViewModel();
//mapping to get information from database and display
ConfigureEditViewModel(job, model);
return View(model);
}
private void ConfigureCreateViewModel(JobCreateViewModel model)
{
model.Title = job.Title;
model.NumberOfPosition = job.NumberOfPosition;
model.Salary = job.Salary;
model.SelectedSalaryPeriodId = job.SalaryPeriodId;
model.PostCode = job.PostCode;
model.SelectedLocationId = job.LocationId;
model.IndustryExperiencePeriod = job.IndustryExperiencePeriod;
model.Role = job.Role;
model.Description = job.Description;
model.SelectedEmploymentHourId = job.EmploymentHourId;
model.SelectedDurationId = job.DurationId;
model.SelectedShiftId = job.ShiftId;
model.SelectedWorkDayId = job.WorkDayId;
}
и при публикации
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Edit(JobEditViewModel model) ---- Using viewmodel
{
if (ModelState.IsValid)
{
//mapping model back to the entity...
var job = new Job()
job.Title = model.Title;
job.NumberOfPositions = .......
repository.Edit(job);
return RedirectToAction("Index");
}
return View(job);
}
При использовании модели просмотра вы сопоставляете объект с моделью для отображения информации, а затем возвращаете модель обратно в объект при обновлении (post action). Я думаю, что у меня что-то отсутствует во время процесса сопоставления, мне кажется, что я постоянно просматриваю между моделью представления и фактической сущностью, мне что-то не хватает (почему используется automapper?).
Я искал в Интернете и, используя View Model, похоже на лучший подход (строго типизированный вид?), Но есть только гораздо больше задействованного кода, который, предположим, произойдет, или я делаю это неправильно.
Да. Правильный подход заключается в том, чтобы сопоставить ваши объекты в viewModel или DTO.
И почему это хороший подход, потому что если у вас есть таблица с 20 столбцами, а на вашем экране, например, используется всего 3 столбца из этих двадцати, то вы можете сопоставить эти 3 использованных столбца и отправить их клиенту, и вы ожидаете, что тот же ViewModel/DTO от клиента, поэтому вы можете построить проверку вокруг этих 3 столбцов только в этом случае.
Если вы не использовали этот аттестат, то вашему клиенту необходимо отправить 20 колонок, даже если на экране клиента не использовалось/установлено более трех столбцов (возможно, вы скажете, что я установлю эти неиспользуемые столбцы на сервере, который может закончиться кодом спагетти, чтобы охватить все случаи, когда ваш клиент использует этот объект).
Надеюсь, это поможет.