Как лучше всего создать класс Model из таблицы БД

Question

Я пытаюсь использовать таблицу. Предположим, что таблица счетов из базы данных содержит 20 столбцов вокруг, и для разных представлений требуются разные столбцы, например, для базовых записей. Мне нужно 10 столбцов для вставки данных из одного отдела и 5,5 из других отделов. , Таким образом, будет 3 представления, которым требуются данные или связь между этой таблицей через модель. Итак, какой подход лучше всего использовать: 1) Создать 3 модели, одна из которых содержит только 10 столбцов, а остальные 5-5? 2) Использование только одной модели, содержащей все столбцы. Разве это не будет нести ненужные данные?

Я знаю, что мы можем разбить эту таблицу и использовать отношения для нормализации данных, но я просто хочу больше узнать о наилучшем подходе, таком как Модель входа в систему и Модель пользователя. Мы можем управлять обоими с одной моделью, потому что нам нужны поля имени пользователя и пароля для обоих, но правильно ли использовать одну модель вместо 2?

Answer 1

Модель и ViewModel представляют отдельные проблемы.Держите их отдельно.Сущность должна отражать состояние данных, в котором вы можете определить модели представлений для поддержки различных представлений представлений.Когда вы загружаете модели представлений из контекста EF через сущности, вы используете .Select(), который будет составлять эффективные запросы SQL только для тех столбцов, которые понадобятся вашей модели представления.

Например, если у меня естьСущность учетной записи с определенными 20 с лишним свойствами, но я хочу представить список учетных записей, в котором указаны только их имена пользователей, время последнего входа в систему и список ролей: (что будет свойством «имени» роли, на которую ссылается таблица AccountRolesсвязывание «многие ко многим» между учетными записями и ролями)

[Serializable]
public class AccountSummaryViewModel
{
    public string AccountName { get; set; }
    public DateTime LastLoginDateTime { get; set; }
    public ICollection<string> Roles { get; set; } = new List<string>();
}


var accounts = MyContext.Accounts
    .Where(x => x.IsActive)
    .OrderBy(x => x.AccountName)
    .Select(x => new AccountSummaryViewModel
    {
        AccountName = x.AccountName,
        LastLoginDateTime = x.LastLoginDateTime,
        Roles = x.Roles.Select(x => x.Role.Name).ToList()
    }).ToList();

Структура сущностей отражает вашу структуру данных, но затем, когда сервер отправляет запрос на эти сущности для обслуживания представления, определите ViewModel для данныхструктура, которую вы хотите отобразить, и использовать EF для составления запроса для заполнения этой модели представления.

Вы также можете использовать Automapper для этого с помощью метода .ProjectTo<T>(), который интегрируется с реализацией IQueryable EF.

EF DbContexts также может иметь только одну зарегистрированную сущность, связанную с одной таблицей.е.Чтобы иметь несколько вариантов сущностей, указывающих на таблицу Account, вам потребуется несколько определений DbContext.Ограниченные контексты полезны для больших систем, но могут привести к ужасно переплетенным контекстным ссылкам при неправильном использовании.

Рекомендуется избегать передачи сущностей в представление, поскольку это может привести ко всем видам проблем производительности, исключениям,а также уязвимости безопасности, особенно если действия контроллеров принимают объекты от клиента.Передача сущностей клиенту Служба передает клиенту больше информации, чем нужно, и вы сталкиваетесь с потенциальными проблемами, связанными с инициированием отложенных вызовов загрузки или отключением сериализации с помощью циклических ссылок.Система также сообщает хакерам / конкурентам больше о вашей структуре данных и данных, чем это должно быть на самом деле.Пользовательский интерфейс может не отображать большую часть информации в объекте, но он отправляет все эти данные клиенту.Для этого требуется больше памяти на сервере / клиенте, а также большая нагрузка по сети.