Должны ли данные форматироваться в бэкэнд или интерфейсе?

У меня есть веб-приложение, и мне интересно, лучше ли форматировать данные в интерфейсе или бэкэнд? Они оба выполняют задание, но кто-то может помочь мне провести мозговой штурм, который является лучшим вариантом между ними.

В качестве примера скажем, что у меня есть бэкэнд, который возвращает семейное дерево имен в определенном формате, но в интерфейсе мне нужно настроить формат в соответствии с форматом, который ожидает виджет, если эта настройка будет выполнена в бэкэнд или в интерфейсе?

Если это делается в бэкэнд, я могу направить данные в виджет в интерфейсе другого, мне придется сначала разбираться в интерфейсе. Может ли кто-нибудь подумать о плюсах и минусах для этой ситуации? Спасибо.

Ответ 1

Отличный вопрос. Я использую многоуровневую архитектуру MVC.

BACKEND

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

Это не означает, что вы должны отправлять содержимое базы данных с каждым вызовом API. Вы должны определенно сравнить модель данных с каждым вызовом, но это должна быть упрощенная версия базы данных ( "естественная" ), а не структура данных, настроенная для определенного вида.

FRONTEND

В передней части я имею плотно связанный контроллер, который получает данные от сервера и преобразует данные в модель, которая хорошо подходит для данного вида. В зависимости от технологии, используемой на стороне клиента, для нее может быть поддержка библиотеки (например, AngularJS для javascript/HTML Swing для Java, WPF для С# и т.д.).

Я нахожу, что эта архитектура приводит к чистому разделению и высокой производительности.

Ответ 2

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

Я бы сделал backend возвратом необработанных данных по умолчанию, но для определенных форматов данных, которые часто требуются интерфейсом, я бы заставил конечную точку backend принять параметр запроса, который сообщает серверу, в каком формате он должен возвращаться данные.

Ответ 3

Я имею дело с этим с другим разработчиком, с которым я работаю. Он любит работать в SQL, и в основном работает там, бизнес-логика, форматирование и т.д. Меня не пугает. По моему мнению (и, по крайней мере, для приложений, над которыми мы работаем) SQL предназначен для обработки хранения и извлечения данных, код сервера/клиентский код предназначен для представления данных пользователю и взаимодействия с пользовательскими взаимодействиями с этими данными.

Это не ограничивается только SQL (или другим движком БД) по сравнению с вашим кодом приложения. В случаях, когда код сервера является скорее API, передавая данные в тяжелое веб-приложение javascript, то же самое. API не знает, что пользовательский интерфейс может делать с данными, целью API должно быть предоставление необработанных данных, и пусть код javascript/презентация имеет дело с его форматированием в требуемом порядке.

Я уверен, что есть исключения из этого, но что общее правило мне нравится. Форматирование выполняется в области представления, а не бизнес-логики или извлечения данных. Держи его там.

EDIT: Я перечитал ваш вопрос, и я думаю, что пропустил тонкий, но важный момент. Если у вас есть конструктор или модель или что-то, что ожидает ввода в определенном формате, может быть разумным сделать это форматирование/преобразование в SQL, чтобы избежать дополнительного шага преобразования данных, прежде чем вы сможете его использовать. Это будет в значительной степени зависеть от проблемы, которую нужно решить, и особенностей того, откуда поступают данные и где они будут использоваться.

Ответ 4

Другим аспектом, который необходимо учитывать, является знание локали (разделитель тысяч, разделитель запятой, формат даты и т.д.).

Если приложение-потребитель предназначено для доступа с клиентов, которые поддерживают локальные настройки (например, веб-браузеры), я предпочитаю как можно больше передавать форматирование во внешний интерфейс. Технически можно отправить языковой стандарт в качестве параметра бэкэнд-API, но современные интерфейсные библиотеки обычно достаточно хорошо обрабатывают языковой стандарт по умолчанию, что значительно облегчает его выполнение во внешнем интерфейсе.

Исключением является ситуация, когда вы точно знаете, что ваша аудитория ограничена только одной локалью.