Здравствуйте, я только сегодня впервые столкнулся с salesforce, почитал статьи Вашего блога и пришел к выводу, что у Вас неплохо получается объяснить работу с новыми технологиями. Спасибо за Ваш труд)
Я, имею достаточное представление о MVC еще из работы с ASP.NET MVC фреймворком, и изучая материал Вашего блога наткнулся на проблему. Где разместить логику приложения? В триггере или в контроллере. Как я понял триггерами следует пользоваться когда имеется стандартный Layout. А контроллером - когда собственное представление. Поясните пожалуйста.
И ещё, прочитав Фаулера, Макконели и др известных людей из мира ИТ мне навязалась тенденция построения архитектуры проекта, разделения его на части (слои): бизнес-логика (домен)(BL), слой доступа к данным (DL), слой представления (PL), ну и как связующее звено между BL и PL - контроллер. В salesforce я четко вижу уровень доступа к данным (запросы, DML), есть слой предствления, который может быть как стандартным Layout так и собственной вьюхой, есть контроллер. И получается что бизнес-логика размазана по всем частям: в контроллере делаются выборки и какие то-то условия + модификация данных, в слое доступа к данным тоже путается логика приложения (в триггере) и Вы еще говорили в какой-то статье, что в представлении можно использовать тоже некоторую логику для вывода данных (скрытие/показ блоков). Для меня это шок. Существуют ли какие-нибудь best practices, архитектурные подходы при разработке в salesforce?
Быть может я что-то не усмотрел, так как только сегодня столкнулся с технологией, но всё же, мне интересно Ваше мнение... Спасибо.
Триггеры имеют ряд ограничений по работе, например callout использовать невозможно, @future (callout=true) метод в триггере тоже не очень хорошо потому что асинхронный вызов при работе с промежуточными результатами и сохранением в БД при условии отработки любого кода после метода @future, может сохранить не понятно что.Надеюсь это понятно 
. Контроллеры как правило создается для страниц которые, также могут переопределять Page Layout, если используется standart Layout можно переопределить standart button (edit,save,cancel) посредствам вызвова web service из javascript.
Для работы с тригеррами в salesforce есть специальный шаблон Фабрика на практике не припомню что бы кто начал реализововать,обычно пишут допольнительный класс где хранят все методы для триггера.
Здравствуйте dlisovsky
Спасибо за интерес к моему блогу. Постараюсь ответить на ваши вопросы.
С ASP.NET MVC не знаком, поэтому привести аналогии у меня не получится. Постараюсь объяснить на пальцах.
Как сказал Сергей в контроллер размещается логика для страницы (Visualforce page) а в триггере логика для события объекта базы данных (вставить записть, изменить, удалить). Насколько мне позволяет сказать опыт, в других платформах аналоги триггеров есть, но они используются крайне редко (обычно их называют обработчики событий и они обычно присутствуют в различных фреймворках). Из-за специфики работы Salesforce триггеры парой являются единственных возможным решением изменить стандартную логику, поэтому их часто используют и про них много пишут.
По поводу где размещать логику - по максимуму в контроллере. Триггеры лучше использовать по крайней необходимости (из-за сложности их создания и ограничений).
По поводу Фаулера, Макконели - все что они пишут вполне можно перенести и на Salesforce. Самый простой вариант программирования - это разместить всю логику в контролере. Но с тем же успехом можно вынести бизнес-логику и слой доступа к данным в отдельный классы. В свое время изучал Spring framework на Java. Там тот же принцип Страница-Контроллер-БД, контроллер сам по себе ничего не делает - вся бизнес логика вынесена в Сервисы, а Сервисы в свою очередь обращаются к отдельным классам, которые работают с БД. Это все конечно красиво и позволяет строить красивые приложения, но на Salesforce некогда заниматься этой красотой и размазывать логику по куче классов. Поэтому вся логика ложится непосредственно в контроллер. (Хотя знаю что java и .net гуру за такое мне руки оторвут )
"вижу уровень доступа к данным (запросы, DML)" - это не уровеь доступа - это просто команды типо SQL (Insert, Updated, Delete). А вот их уже должен использовать "уровень доступа к данным" по принципу описанному выше.
"в представлении можно использовать тоже некоторую логику для вывода данных (скрытие/показ блоков). Для меня это шок" - вот тут ничего как раз шокирующего нет. В любом фрейворке в представлениях такие возможности присутствуют. Те же JSP в Java. Показать тот или иной участок разметки в зависимости от каких-то условий, которые пришли из контроллера. Salesforce тут ничего нового не придумал.
Вся best practice находится здесь http://developer.force.com/ . Нет ничего лучше официальной документации.
Скажу еще такое, по опыту своей компании. На Salesforce тяжело приходится тем, кто имеет опыт работы с другими фреймворками, особенно если использовал до этого всякие паттерны проектирования и всякие умные штучки. У нас был один человек, который на Salesforce начал использовать всякие интерфейсы, размазывать логику по различным классам, в общем, делать красиво. Пришлось переучивать
Удачи в изучении.
Вот еще очень хороший ресурс по Salesforce архитектуре http://advancedapex.com/ .Если у кого нибудь есть ссылка где можно скачать бесплатно эту книгу поделитесь плиз.
Дима, не совсем согласен c высказыванием. "Делать красиво". Если человек "делает красиво", то он не понимает, что такое интерфейс и для чего он нужен.
Ох, больная тема про эти интерфейсы, наследование и всю эту "красоту". Я сам до недавнего момента был противник этого, потому что, ты верно подметил, "надо понимать зачем все это нужно". Вот тут начал переваривать ряд статей про паттерны проектирования в проекции на Salesforce. Очень интересная и полезная информация, которая вдохновляет писать красиво и правильно.
НО проблема в том, как все это воплотить в практику. Начну я один раскладывать код на службы, доменные объекты, слои. То 10 моих коллег явно не обрадуются таким изменениям и расползанию кода.
Так что тут можно долго рассуждать про быстро или красиво :)
Воплощать нужно, начиная с себя. С другой стороны встает чисто психологический вопрос.
Например, видишь код, который писал, условно, "индус". Ладно, если этот код видит матерый программист, а если это видит Junior, который только-только познал азы программирования. Он посчитает это правильно и будет так решать проблемы до пенсии.
Другое дело, если человек подает пример, ведь хорошему этикету уже в университетах не учат. Так, что Дима, не стесняйся...подавай пример, своим коллегам, уверен - со временем все останутся довольны не только в эстетическом, но и архитектурном плане :)
Спасибо Art Vegas за поддержку )
После написания статей возмусь за наглядную агитацию среди коллег. Хотя с нашиим живими проектами, когда время наш главный враг, остается вспомнить одного гуру salesforce (жаль забыл где видел) - "нафиг все эти паттерны, клиенту важно чтобы работало" )))))
