Gres, в соседней теме ты упоминал DTO.
Последнее время (в связи со сменой основного рабочего проекта) стал открывать для себя ООП (оказывается до этого то что я знал про ООП и шаблоны проектирования, можно сказать что вообще ничего не знал).
В общем столкнулся с понятием DTO на новом проекте и его повсеместном использовании. По коду видно что можно обойтись спокойно и без него, но несмотря на это DTO активно используют.
Хотел ты тебя попросить написать немного от себя про DTO, что это, зачем ты их используешь и в чем преимущество их использования. Я думаю будет полезно не только мне.
Предлагаю вообще организовать "неделю ООП в Salesforce" 
и рассказать какие шаблоны проектирования и ГЛАВНОЕ ДЛЯ ЧЕГО вы используете.
Немножко ссылок:
Data transfer object
what is Data Transfer Object?
Суть в том, что формат и структура хранения данных в БД и на клиенте может значительно отличаться, чтобы отдать необходимые данные клиенту, ты должен преобразовать их в определенный формат, который называется DTO.
Таким образом, клиент не знает, как хранятся данные в БД, и не зависит от их формата. А когда нет жестких зависимостей не составит труда изменить формат, как на клиенте, так и в БД.
Сорри, за некропостинг, но забавная у вас неделя ООП получилась :)
Да, поучительная :)))) Много интересного узнали и выслушали мнение каждого.
Кстати RasMisha если я правильно помню что ты мне возразил по поводу того что в Salesforce нет документации по поводу паттернов проектирования (официально желательно) но я так ответа и не услышал про то где ее найти.
О!
У меня они везде. Только называются Wrapper 
Так уж повелось до меня, ну и мне вообщем-то пофик как оно называется, лишь бы работало и было понятно.
Так как я на сервисах сижу, то это одно из основных, с чем я работаю.
Ессесно, передавать объект клиенту со всем мусором нет смысла. Передаем только то, что надо. При чем есть базовые DTO, а есть уже с полным набором полей. Периодически, надо возвращать только базовый, в котором только ID есть, ибо такой объект уже загружен на клиенте. Например, если объект содержит список объектов. То в этом списке, порой, передается только ID.
До меня все DTO содержали поля errorMessage и что-то еще. Ну и они всегда приходили, даже если пустые. А если это список, то, ну сами понимаете. Выпилил я это и засунул errorMessage в header ответа.
Специфика приложения такая, что даже в США, не везде хороший тырнет. А в моем конкретном случае, когда работничег находится в "бункере", то ну очень медленно. Так что, чем меньше пакет, тем лучше.
Опять таки, поля тоже называются коротко, а не такоетоСуперПуперОфигенноеПоле
Внутри нигде не передаю их, только sObject.
