Как структурировать решение модели данных клиент – сервер? - PullRequest
Новая
       105

Как структурировать решение модели данных клиент – сервер?

0 голосов
/ 14 июля 2020

Мне нужно написать клиент-серверное решение. Сервер будет выполнять запланированные операции, а также передавать данные из SQL БД клиенту.

Клиент еще не полностью определен, но он будет делать запросы на сервер и отображать данные для пользователя и передавать данные обратно для сохранения.

Все решение имеет дело с сущностями (Пользователи, продукты и т. д. c. с их связанными атрибутами).

В моей голове и сервер, и клиенту необходимо знать об этих сущностях, чтобы ими можно было эффективно манипулировать в коде, вместо того, чтобы распаковывать JSON и дублировать код.

Мой вопрос: должен ли я создать библиотеку классов, содержащую модели (классы или структуры), представляющие эти сущности, на которые ссылаются как клиентские, так и серверные проекты?

В противном случае, есть ли какой-нибудь стандартный способ создания такого решения? клиент, сервер (на основе ASP. NET 2) и библиотека классов, содержащая модели сущностей вместе с некоторыми логами доступа к данным * 102 1 *. И клиентский, и серверный проекты ссылаются на библиотеку классов. Однажды я уже начинаю сомневаться в том, что мой подход слишком неуклюжий.

Я буду работать с VS2019, используя C#.

1 Ответ

0 голосов
/ 15 июля 2020

Это не совсем тот вопрос, который подходит для StackOverflow, который нацелен на решение определенных c проблем кода / технологий.

Можно использовать одну и ту же модель (Entity) как на клиенте, так и на сервере, но я настоятельно рекомендую отделить клиентскую модель (модель представления) от модели предметной области. (Сущность) Причины для этого:

  • Клиенты редко нуждаются или должны предоставлять все поля и отношения домена. Отправка моделей с сервера на клиент включает сериализацию. Это может привести либо к проблемам с производительностью, либо к ошибкам, поскольку сериализатор "касается" свойств и хочет их отложить, или вы добавляете стоимость загрузки всего с нетерпением; Или это приводит к неполным моделям, в которых незагруженные отношения остаются нулевыми. (Не потому, что их нет, они просто не были загружены). Клиентские модели следует обрезать до тех данных, которые клиент должен видеть, отформатированных таким образом, чтобы он мог их использовать. В конечном итоге это отправляет клиенту и обратно больше данных, чем необходимо. Сохраняйте полезные нагрузки по сети как можно меньше.

  • Безопасность может быть проблемой при передаче объектов от клиента к серверу. Ваш пользовательский интерфейс может позволять пользователям изменять только несколько значений определенным образом, но может возникнуть соблазн взять этот объект, присоединить его к контексту БД и обновить его. (Обновления в 1 строку) Однако этот объект, отправленный от клиента, может быть легко изменен браузером, что может привести к внесению изменений, которых вы не ожидаете / не разрешаете. (Т.е. изменить отношения FK) В лучшем случае это может позволить перезапись устаревших данных, когда изменения, сделанные после того, как эта запись была отправлена ​​клиенту, перезаписываются без уведомления, когда клиент пытается отправить свое изменение. Не доверяйте данным, полученным от клиента, особенно с целью «экономии времени». Запросы на обновление должны проверять поступающие данные и повторно загружать Entity для проверки таких вещей, как версия строки, перед обновлением разрешенных значений.

Включение моделей представления может быть выполнено с использованием техники, поддерживаемой в EF называется Проекция. Это может быть написано от руки с использованием .Select или с использованием таких инструментов, как Automapper и его метод ProjectTo, чтобы легко преобразовывать сущности и выражения Linq в простые, глупые сериализуемые модели представления. Когда модель представления возвращается на сервер, вы просто загружаете объект и ассоциации из БД по идентификатору и обновляете значения после этапов проверки и SaveChanges для сохранения.

...