Передача модели на уровень данных для двух или трех параметров в Angular - PullRequest
Новая
       17

Передача модели на уровень данных для двух или трех параметров в Angular

0 голосов
/ 06 мая 2019

Я работаю над проектом Angular (v6) на ASP.NET MVC для бэкэнда и Entity Framework. Иногда есть некоторые операции CRUD, которые обновляют только 2-3 поля на объекте, и в этой ситуации я могу быть озадачен тем, какой подход будет лучше для лучших практик для этого сценария. В качестве примера, скажем, у меня есть сущность Employee со следующими свойствами, показанными ниже:

Сотрудник: Id, Статус, Имя, Фамилия, Работа, Отдел, HireDate, Дата рождения, Адрес, Обновлено ...

Предполагая обновление для полей Статус, Отдел и Обновление, я могу выполнить это для следующих подходов:

Подход I:

Я могу создать экземпляр файла employee.ts и заполнить его в component.ts только полями, которые необходимо обновить, а затем передать его в service.ts и передать в Controller.cs. В Контроллере я получаю модель как модель сущности Employee и устанавливаю поле «Обновленный» в Controller и передаю эту сущность Employee в Service.cs, а затем сохраняю эту сущность, используя связанные методы EF.

Подход II:

Я просто отправляю значения Id, Status и Department из Component.ts в service.ts, а затем передаю их в контроллер как значения int (Id). Затем в контроллере создайте новый экземпляр сущности Employee.cs и заполните эти 3 поля и поле Обновление. Затем передайте эту сущность в Service.cs и затем сохраните эту сущность, используя связанные методы EF.

Подход III:

То же, что и подход II до Controller.cs. Затем передайте эти 3 параметра в Service ts и затем извлеките Сотрудника из базы данных через параметр Id. Затем установите другие поля и сохраните объект.

Я думаю, что 3 из них можно использовать, но не уверен, какой из них лучше для этого сценария в проектах Angular с EF? Любая помощь будет оценена ...

1 Ответ

1 голос
/ 07 мая 2019

Подход 3 или

Подход 4: Создайте UpdateEmployeeViewModel с полями PK и, которые вы хотите обновить, чтобы заполнить их в своем TS, передать контроллеру, который проверяет данные, загружает объект, передает соответствующие значения и сохраняет. Когда это один или два столбца, то подход 3 хорошо. Если он вырастет до большего, я обычно выбираю # 4.

Я бы избегал подхода 1 любой ценой. Слишком удобно, чтобы код доверял объекту, переданному от клиента. Вызов к вашему сервису может быть перехвачен и скорректирован, так что если ваш серверный код принимает сущность, вы можете легко найти код, который выполняет DbSet.Update или DbSet.Attach, что может привести к сохранению подделанных данных в базе данных.

Подход 2 также оставляет проблемы при выполнении обновлений, поскольку сущность всегда должна отражать свою строку данных. Создание сущности и ее частичное заполнение, а затем попытка обновить состояние данных может привести к непреднамеренным обновлениям, таким как очистка значений. В будущем у вас могут быть другие распространенные методы, которые принимают сущность в качестве параметра, но у вас есть случаи, когда переданная сущность может быть полной (загружена из БД) или неполной (построена методом обновления)

Загрузка объекта по идентификатору довольно быстрая, поэтому редко возникает необходимость в чрезмерной оптимизации. Это также может помочь проверить версию строки #, чтобы убедиться, что версия обновляемой сущности совпадает с версией, еще находящейся в БД. (Кто-то еще обновил эту строку, так как вы изначально отправили ее клиенту?)

...