Могу / должен ли я делиться классами моделей между клиентом и веб-API?

#c# #rest #inheritance

#c# #rest #наследование

Вопрос:

Я пишу клиентское приложение Blazor WebAssembly. которое взаимодействует со службой веб-API. Я использую DTO для передачи данных между ними, так что у меня все хорошо. Проблема в том, что есть несколько довольно сложных классов с множеством свойств и множеством методов, которые необходимо совместно использовать как на клиенте, так и на сервере. Я не хочу дублировать тонны кода. Я думал о том, чтобы поместить общие части в сборку, которая используется как клиентом, так и сервером, возможно, с использованием наследования (например, у PlayerCommon есть дочерние элементы PlayerClient и PlayerServer), но я столкнулся с проблемами с дальнейшим наследованием (например, MachinePlayer является дочерним элементом PlayerServer).

Существуют ли рекомендации по выполнению этого (или не делать этого)? Я хочу максимально упростить его и свести к минимуму количество дублирующегося кода. Я думал об использовании частичных классов, но я не думаю, что это работает во всех сборках.

Спасибо за ваше время, я ценю это.

Комментарии:

1. Это своего рода один из основных преимуществ использования одного и того же языка на стороне клиента и сервера.

2. Если у него «много методов», действительно ли это DTO? С практической точки зрения совместное использование классов POCO, безусловно, удобно. Если есть хоть какой-то шанс, что это будет внешний сервис, вам, вероятно, лучше использовать что-то вроде swagger, чтобы клиенты могли легко создавать свои собственные классы poco.

Ответ №1:

При условии, что вашим потребителем является приложение dotnet, совместное использование запросов / ответов / DTO API очень полезно.

мы используем следующую настройку:

  1. Имяпроекта.ApiModels — проект .net standard 2.0 без каких-либо зависимостей, который просто определяет классы, используемые в действиях запроса / ответа. Этот проект ссылается на проект.Веб, который содержит все контроллеры.
  2. Имяпроекта.Клиент — проект .net standard 2.0, который создает HttpClient и добавляет операции вокруг доступных методов.

Таким образом, клиентские и серверные приложения могут использовать разные фреймворки, например.net core, .net framework.