Имя свойства API выходной модели

Question

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

Answer 1

В вашем коде должно быть как минимум 3 слоя объектов: ViewModel, Dto и Entities.

Каждый слой должен видеть только слой непосредственно под ним.

Итак, Ваш сервисный уровень может читать сущности из вашего уровня данных, но если он предоставляет какие-либо объекты, они должны быть в Dto.

Тогда ваш уровень представления (UI / API et c) будет читать из сервисный слой (DTO) и выставьте его объекты как ViewModels.

Во многих случаях это означает, что все 3 объекта (Entity, Dto & ViewModel) имеют одинаковые повторяющиеся свойства, но этого следует ожидать, особенно в небольших или новых проектах.

Это должно решить ваши проблемы с именами.

Уровень данных: XXXEntity

Уровень обслуживания: XXXDto

Уровень представления: XXXViewModel

Это объяснение очень упрощено, и вы можете решить эту проблему различными способами (например, вы можете использовать пространства имен вместо суффиксов классов).

Answer 2

Руководство, которое я пытаюсь выполнить, заключается в том, что наименование должно отражать намерение - тогда как пользователь просто представляет концепцию «пользователя» в вашем домене, модель API предназначена для использования в качестве полезной нагрузки API, содержащей пользовательскую информацию. На вашей позиции я бы рассмотрел что-то вроде UserApiModel или UserPayload.

* В качестве дополнительной заметки, за мои деньги самое важное здесь - это последовательность - независимо от того, что вы выбираете, что имеет смысл для вас сейчас, возможно, не самое интуитивное для вас (или кого-либо еще) поддержание кода позже. Пока вы применяете соглашение об именах последовательно ко всем своим API-моделям, не стоит слишком сильно беспокоиться о поиске «правильной» - просто выберите первую, которая кажется достаточно хорошей , и продолжайте катиться.