Блог

Недавно я начал разработку в .NET core.

При разработке я столкнулся с ситуацией, когда мне приходится создавать очень похожие модели, которые не совсем одинаковы. Например, давайте поговорим о модели бронирования:

Интерфейс: здесь мне нужна модель, которая публикуется в виде JSON в моем бэкэнде и преобразуется в своего рода модель FrontendBooking.

Серверная часть: мне нужно добавить данные клиента в бронирование, поэтому мне нужно добавить такие поля, как: CustomerName и CustomerAddress, на основе их CustomerID. Серверная часть должна предоставлять эти данные, я не хочу, чтобы интерфейс определял эти поля. Я объединяю эти модели, чтобы подготовить их к вызову API. К модели под названием RequestBooking.

API: я отправил RequestBooking в API и получил ответ с объектом similair, который имеет, например, статус и добавленный идентификатор бронирования, это было добавлено в модель API. Итак, мне нужно десериализовать это в объект с именем: ResponseBooking .

База данных: Наконец, я хочу сохранить объект в базе данных, однако не все свойства модели актуальны, поэтому я создаю другую модель с именем: DatabaseBooking и сохраняю ее в базе данных.

Когда свойство добавляется, удаляется или изменяется. Тогда мне придется изменить его для каждой из этих моделей.

Есть ли шаблон проектирования или какое-то другое решение, чтобы это было более управляемо?

Кроме того, как лучше всего называть эти модели? Называть их все Booking не совсем правильно, и добавлять, для чего они используются, тоже не совсем правильно.

Заранее благодарю.

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

Сервер: здесь вы можете использовать дизайн, управляемый доменом. У вас будет резервирование объекта, которое отвечает за его логику и содержит все свойства и методы, такие как, например, MarkAsCancelled . Вы можете использовать Entity Framework для использования того же объекта в базе данных, который будет соответствовать таблице базы данных. EF позволяет пометить некоторые свойства как не сохраненные в базе данных. Также вы можете настроить EF в классе DbContext и, таким образом, не использовать атрибуты, специфичные для DB, в классе. Итак, один объект для бизнес-логики базы данных и серверной части.

API: очевидно, что вы не можете отправить свой доменный объект в API, например, REST. В API вы можете захотеть объединить свойства нескольких объектов домена или скрыть некоторые свойства. Вам нужно будет определить набор объектов передачи данных (DTO), например BookingDto . Как преобразовать объекты вашего домена в DTO? Могут помочь такие решения, как AutoMapper. Вы просто настраиваете правила преобразования один раз.

Теперь вы можете описать свой API, например, в Swagger. С помощью Swagger Codegen вы можете генерировать код для своего сервера (.net) и клиента (например, JS).

В конце концов, вам придется поддержать следующее:

• Определение API (например, Swagger). Код для DTO сервера и клиентских объектов генерируется автоматически. Вы изменяете определение API один раз, обе стороны получают новые объекты.
• Модели DDD, которые также используются для базы данных. Они могут быть совершенно независимы от ваших DTO. Сопоставление обрабатывается для вас полуавтоматически, например, Automapper

Все сказанное — всего лишь предложение. Все слои и количество объектов могут и должны быть адаптированы к конкретным потребностям вашего проекта. Например. вы можете захотеть использовать отдельные объекты для базы данных, если вы не используете реляционный картограф, такой как EF, или не хотите смешивать БД и логику.