Как вы знаете, "подключить" LWC к "базе данных" можно через @wire проперти или функции, используя как стандартные "методы", так и методы своего кастомного APEX контроллера.
Но в суровой реальности "легкие" способы через @wire не всегда помогают, и нужно империтивно вызывать методы APEX контроллера.
Ну так вот, как правильно наладить "обмен данными" между LWC и APEX контроллером. Понятно что АПЕКС метод что-то принимает как аргументы и что-то возвращает. Вопрос в том, что именно.
И здесь я вижу несколько вариантов, и они все рабочие, поэтому и не ясно, что именно лучше, и об этом и тема, чтобы все обсудить.
Варианты:
(1) Апекс метод принимает и возвращает объект данного Контроллер класса, где его проперти используются как "View State" в традиционной модели. Такой подход - это скорее "антипаттерн", но позволяет хоть как-то выжить в среде LWC свеже-прибывшим с Visualforce page разработчикам.
(2) Апекс метод принимает и возвращает Strings. Тут самое интересное, что делать с объектами-записями, которые нужно передавать массивами. Они серилизуются перед отправкой и десерелизуюся в объекты по прибытию в нашем коде, причем может использоваться специальный апекс класс для создания таких транспортных объектов. При получении стринга как аргумента в апекс, он парситься:
(List<My_Class>) System.JSON.deserialize(json, List<My_Class>.class);
что-то подобное нужно делать и на стороне LWC контроллера
(3) Зачем возиться со стрингом, если записи-объекты можно передавать между LWC и APEX без явной стрингификации.
То есть Апекс метод принимает List<My_Class> (или List<sObjects>) и возвращает List<My_Class> (или List<sObjects>). В таком случае проще, так как не нужно "парсить" стринги в собственном коде. Но тем не менее я вижу, что люди упорно серилизуют так, чтобы апекс методы принимали только стринги и возвращали стринги.
Но нужно ли это делать? как лучше? какие преимущества и недостатки между String VS List<My_Class> (или List<sObjects>) ?
Преимуществ я лично не вижу, но вижу недостаток в нерациональном расходовании ресурсов на serialize и deserialize
Не всегда получается корректно передать без сериализации например такую штуку object[], я говорю передачу от клиента в апех
Да, я тоже за явную сериализацию в String и отправку именно стринга.
Не стоит доверять внутреннему сериализатору SF. Было куча косяков в прошлом - он не так сериализует как простые
JSON.serialize/deserialize!
К тому же ручной подход позволяет проконтролировать что ты отправляешь и даже возможно закешировать/залогировать на память. Стрингу то точно по пути к клиенту никто не поменяет. А если отправлять объект потом будешь долго объяснять что за кашу получил клиент.
Клиент тут понятие собирательное (LWC/Angular/Внешний сервис)
