Блог

В примере с EmailContacts свойства контакта перечислены в классе Contact и в классе CreateContact. (нет класса UpdateContact, который также понадобился бы приложению реального мира)

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

Я бы сначала ознакомился с концепциями ServiceStack Backgrounds для получения дополнительной информации, в частности, почему удаленные службы должны использовать DTO, в которых говорится, что свойства DTO декларативно определяют назначение каждого типа, т. Е. Их Не следует рассматривать как дублирующуюся логику, которую вы хотите скрыть за сухими методами. Он также включает встроенные примеры автоматического сопоставления, показывающие, как вы можете легко сопоставлять между различными типами.

Это разные типы для разных целей, например. типы операций CreateContact , UpdateContact определяют входные данные для каждой операции, в то время Contact как определяет модель данных, это типично для каждого из этих разных типов, которые различаются в зависимости от того, какая схема разрешена при первом создании объекта, обновляется или сохраняется в модели данных.

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

Для более крупного реального примера ServiceStack вы можете ознакомиться с базой кода для https://techstacks.io доступно на GitHub по адресу https://github.com/NetCoreApps/TechStacks