#c# #sql #asp.net #kotlin #backend
#c# #sql #asp.net #kotlin #серверная часть
Вопрос:
Я отдыхаю asp.net ядро с некоторым API, который я буду использовать с приложением для Android позже.
У меня есть некоторые сомнения по поводу некоторых операций с базой данных.
Давайте предположим, что у меня в моей базе данных есть тикеты таблицы, в которых есть столбцы id, title и author (это внешний ключ, который ссылается на таблицу пользователя (id — name)) Теперь, когда приложение Sndroid запрашивает список заявок, я сделал выбор и вернул идентификатор, название и имя автора, поэтому я создал билет класса следующим образом:
class Ticket{
private int id{get; set;}
private string Title {get; set;}
private string author {get; set}
}
Теперь предположим, что приложение отправляет POST-запрос для добавления нового билета. Какова наилучшая практика?
Отправьте заголовок и имя автора (у клиента есть копия таблицы author в локальной базе данных) или заголовок и идентификатор автора.
Итак, в первом случае у меня есть класс для нового билета, подобный приведенному выше (без идентификатора), и я должен сделать выбор, чтобы получить идентификатор автора и сделать вставку в БД. Во втором случае у меня есть такой класс:
class Ticket{
private string Title {get; set;}
private int author {get; set}
}
и нет необходимости делать выбор, чтобы получить идентификатор автора.
Какой из них лучший? иметь два разных класса или только один с несколькими операциями над БД (чтобы получить идентификатор автора).
Теперь я упростил пример, но представьте, что в билете больше столбцов с внешними ключами, что лучше?
Ответ №1:
Вы должны понимать, каковы объекты вашего домена. Из описания я бы сказал, что у вас есть как минимум два: author и ticket.
В этом случае автор создает тикет, например, в POST authors/{AuthorID}/tickets . В этом случае вы возвращаете тикет обратно, т.Е. Без идентификатора автора, потому что автор уже известен клиенту (TicketDTO: id, title . Смотрите на DTO ниже).
Также то, что вы отдаете в любом конкретном EP, зависит от ваших бизнес-требований, то есть от потребностей клиентов вашего API. У вас много клиентов, некоторые из которых 3d party? Сделайте свой API как можно более универсальным. У вас есть один клиент, который вы пишете сами, и вы уверены, что другие клиенты не придут? Возвращайте больше информации, если вам нужно, особенно если вы можете сохранить некоторые вызовы и, таким образом, повысить производительность.
И последнее, но не менее важное: объект, который вы получаете из базы данных, не является объектом, который вы отправляете через REST API (DTO). DTO может содержать информацию из нескольких объектов БД. Вы создаете свою базу данных на основе своих потребностей в бэкэнде, а REST API — на основе потребностей вашего клиента. И затем вы сопоставляете объекты БД с DTO, например, с помощью AutoMapper или какого-либо другого решения.
Комментарии:
1. Хорошо, но, например, когда клиент отправляет запрос GET, чтобы получить список билетов, я должен вернуть идентификатор, название и автора для каждого билета. База данных уже существует, и я должен создать с ее помощью серверную часть. Мой вопрос таков. что лучше всего подходит для POST-запроса? отправить напрямую идентификатор автора или отправить его имя, и после этого серверная часть сделает выбор, чтобы получить его идентификатор и сделать вставку в БД?
2. Я бы сказал, что с помощью post вы отправляете идентификатор автора, и не как полезную нагрузку post, а как часть URL: POST authors/{AuthorID}/ tickets . При необходимости сервер запросит автора и вставит тикет в базу данных. С get это зависит. Запрашивает ли клиент всех авторов, а затем их заявки? Чем автор является вашим совокупным корнем, и у вас есть GET authors и GET authors/{AuthorID}/tickets . Ваш клиент запрашивает список заявок? Тогда у вас есть GET tickets и GET tickets/{TicketID}/author или просто включите author в ticketDTO: {id, title, author: {id, name …}} .
3. Это действительно зависит от потребностей вашего приложения. REST дает рекомендации, как что-то делать, а не жесткие правила. Сначала определите свои ресурсы, подумайте об их отношениях. Что является основным ресурсом (совокупный корень)? ПОЛУЧИТЕ их напрямую, например, GET myresources . Какие ресурсы имеют смысл только тогда, когда вы уже запросили совокупный корень? ПОЛУЧИТЕ их через основной ресурс, например, GET myresources/id/mysubresources . Нормально ли, чтобы клиент делал много запросов? Создайте универсальный детализированный API. Клиент ограничен в ресурсах? Создайте более крупные DTO и включите в них больше информации.
4. Да, клиент делает запрос GET, чтобы получить все билеты. Чего я не понимаю, так это какой подход лучше: когда клиент отправляет СООБЩЕНИЕ, чтобы вставить новый тикет в БД, он отправляет заголовок и свой идентификатор или заголовок и свое имя (и сервер будет искать его идентификатор)