Эта статья морально устарела :( . Приглашаю продолжить ваше знакомство с Salesforce на нашем Форуме!
Привет друзья. Начинаю цикл статей "Паттерны проектирования бизнес приложений на. (Application Enterprise Patterns)" о принципах проектирования сложных бизнес приложений на Salesforce. Красивое и подробное описание данных концепций дал Martin Fowler, а помог переложил их на реалии Salesforce Andrew Fawcett, на основе чьих статей я и буду строить свои материалы.
Данная тема очень актуальна, когда вы выходите на уровень работы с целым приложением, особенно, что касается его проектирования. На моей памяти есть несколько проектов, с которыми я столкнулся, где этап проектирования был упущен и многие годы задачи решались в лоб – есть задача вот тебе Visualforce page+controller, trigger или batch. Ни о каком либо повторном использовании кода и речи не шло. Теперь поддерживать такое приложение сущий ад и новые фичи лишь только усложняют ситуацию. До недавнего времени я сам придерживался такого мнения, что нужно делать просто, быстро и с нуля. Даже где-то советовал в комментариях "не заморачиваться" с различными паттернами проектирования. Каюсь, буду исправляться. Перевод статей позволит и самому разобраться и польза для русского сообщества надеюсь будет.
Разделение ответственности (Separation of Concerns) определение wikipedia Сложный код часто выходит из-под контроля, когда вы не задумываетесь о правильном разделении задач. Код становится помойкой из изначального кода, костылей и багов :). Если тому, кто работал изначально с таким кодом, еще можно как-то разобраться, то для нового разработчика проект станет огромной проблемой.
Вынесение общих логических задач и предоставления к ним доступа из разных мест вашего приложения – это первый шаг на этапе создания повторно используемого кода и разделения ответственности. Salesforce уже позаботился о нас и предоставил шаблон проектирования MVC из коробки (Model -> Objects, View->Visualforce pages, Controller-> Apex code). Это минимальное разделение подходит разве что для небольших приложений с простой логикой. Недостаток данного подхода в том, что основная разработка ведется в контроллерах страниц, где скапливается весь код, и повторное его использование для другой страницы просто сводится к copy-past. Смысл
Разделения ответственности - капнуть еще глубже и разделить приложение на еще более мелкие составляющие. Результатом данного подхода должно стать вынесение всей бизнес логики из контроллеров страниц и разбиение ее на слои. Это позволит «отвязать» бизнес логику от конкретной страницы, минимизировать сам контроллер и сделать код доступным из разных мест. В следующих статьях мы начнем рассматривать такие понятия как Service layer, Domain layer и Selector layer (Data Mapper) и порядок их использования. (кто знает как правильно перевести на русский данные понятия, буду рад подсказке)