Workflow Rule + Field Update VS Apex Trigger

Workflow Rule + Field Update VS Apex Trigger

Провокационный вопрос: Что лучше - написать Workflow Rule с Field Update'ом или использовать Apex Trigger? Естественно предполагается ситуация с которой Workflow Rule и Field Update могут справиться.

ilya leshchuk
Провокационный вопрос: Что лучше - написать Workflow Rule с Field Update'ом или использовать Apex Trigger? Естественно предполагается ситуация с которой Workflow Rule и Field Update могут справиться.

Все зависит от задачи.
Лично, я за стандартные решения, так как их проще поддерживать.
+Workflow Rule с Field Update'ом

Я за триггер.
Не люблю размазывать логику по salesforce как масло по батону.
Потом это становится нереально поддерживать, особенно на большом проекте.
Код есть код, а всякие галочки быстро забываются и потом очередной разработчик ломает голову почему у него хрень какая-то происходит.
Всякие workflows, validation rules и так далее считаю лишь игрушкой для клиента и тупо маркетинговым ходом.
Это позволяет клиенту решить примитивные вопросы без разработчика, но если уже дошло дело до разработчика, то нафиг эти все штучки.
Чистый код!

Дмитрий, извини, конечно)
Но не хотел бы я с тобой работать в команде

Да я уже понял
Мне ваша компания уже 2 раза отказывала
Ну вот и третий

Ну это всего лишь политические взгляды.
Сам то я вполне себе спокойно подстраиваюсь под любые проекты.
Сейчас отлично работаю на проекте с таким ООП что уши заворачиваются (я уже упоминал про 5-6 apex классов чтобы просто вывести sidebar на странице). Ничего тоже ООПю по полной

На самом деле это в какой-то мере шутка. Просто не понимаю твою нелюбовь к вещам из коробки.
Потому что проект (s-d.net) в принципе ничего так выглядит)
Думаю если б работали вместе, то сработались бы.

первое правила Salesforce: используй стандартный функционал везьде где только возможно.

идеальная работа разработчика - это показать твоим БА, что все что они хотят можно сделать поинт-энд-кликом и показать им как делается. На себя брать действительно сложные и интересные задачи.

но ситуации конечно могут быть разные.

Den Brown
На себя брать действительно сложные и интересные задачи.

+1

Да я понимаю, тоже шучу.
Конечно если серьезно будем разговаривать (по работе), то все будет совсем по другому.
И я буду любить и знать как использовать стандартные штуки и с ООП все нормально будет.

Просто выражаю свои мысли исходя из прошлого опыта работы на проектах с большой текучкой.
Ну сколько раз видел что начинается все круто, а заканчивается в темном месте, потому что текучка, дедлайны, изменяющееся ТЗ или его отсутствие.
Поэтому я понял что все должно быть лаконично, в одном месте и максимально независимо от остального, вплоть до копипаста. И разрабатываться одним человеком. Это реальный мир

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

RasMisha
Потому что проект (s-d.net) в принципе ничего так выглядит)

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

RasMisha
Думаю если б работали вместе, то сработались бы.

А куда бы я делся

Den Brown
идеальная работа разработчика - это показать твоим БА, что все что они хотят можно сделать поинт-энд-кликом и показать им как делается.

Ага, я потом посмотрю на вас в 2 часа ночи, когда бешеный клиент будет звонить и кричать в трубку что ваша страница не работает. Хотя до этого он просто повесил на объект validation rule и сломал вашу страницу.

Никогда не доверяйте клиенту/пользователю.
Ну или пока не достигнете уровня Дзен, чтобы разрабатывать код с учетом всех защит от дурака!

Еще раз повторю.

Когда все это один делаешь или все это делается под руководством 1 человека то можно играться всеми этими настройками и стандартными инструментами. Но если работа ведется параллельно (девелопер-девелопер, девелопер-клиент) то я могу пожелать только удачи.
Проходили не раз. Отлавливали бешеные(незарегистрированные в нашем ТЗ) workflow, time-based workflows, validation rules. Скажу, ничего приятного в этом нет.

Помню свой предпоследний проект.
Огромную полезную мысль вынес оттуда.
"Убрать от пользователя ВСЕ лишние элементы интерфейса или логировать каждый чих".
Знаете что было в проекте от стандартного salesforce? НИЧЕГО.
Были только кастомные страницы с 1-2 большими кнопками, которые еще нельзя было нажать не вовремя.
Потому что девочкам сложно и вы не представляете что они способные вытворить даже с этими 2 кнопками.
А если дать им еще стандартный UI от salesforce - будет беда.
Вы же поймите что работать будут не такие же как вы программисты Salesforce и не продвинутые пользователи, а бизнесмены, бухгалтерши, для которых чайник уже сложно.

Не, я говорил про код на github

Я БЫЛ БЫ СЧАСТЛИВ!!!
если бы salesforce предложило такое решение:
custom objects + apex + visualforce и ВСЁ!!!
Я думаю он бы пользовался успехом у русских клиентов

RasMisha
Не, я говорил про код на github

Знаешь, вот как раз с кодом там не очень.
Он красиво выглядит потому что это python
Но в плане организации проекта там далеко от идеала.
Как раз это типичный пример того что вы так с Gres не любите - отсутствие какой либо архитектуры и портянки кода.
По нормальному это все дело рефакторить и рефакторить

Dmitry Shnyrev
По нормальному это все дело рефакторить и рефакторить

Согласен, но читать я смог. Это уже, как минимум, не мало.

В этом и есть прелесть python и ruby. У них очень понятный и красивый синтаксис.
Java enterprise и рядом не стоит в плане красоты кода.

Сорри, опять затеял холивар

я кстати за триггер)
было у нас wfr + fu на практике. жопа еще та

ну допустим так, а теперь резко меняем задачу на email alert

RasMisha
ну допустим так, а теперь резко меняем задачу на email alert

ну так в чем проблема

делай вфр + алерт

тут стоит конкртная задача, а не допустим, меняем, и тд

Maxim Elets
ну так в чем проблема

делай вфр + алерт


То есть логика будет разнесена в триггер + вфр?

Maxim Elets
тут стоит конкртная задача, а не допустим, меняем, и тд

Вот тут я вообще не соглашусь, поменять или добавить поведение могут в любой момент.

RasMisha
Maxim Elets
ну так в чем проблема

делай вфр + алерт


То есть логика будет разнесена в триггер + вфр?

как будто ты никогда такого не встречал)?

RasMisha
Вот тут я вообще не соглашусь, поменять или добавить поведение могут в любой момент.

И в чем будет проблема? email это одно, апдейт филда это второе

Maxim Elets
как будто ты никогда такого не встречал)?

Я и надписи на заборах встречал

Maxim Elets
И в чем будет проблема? email это одно, апдейт филда это второе

То что на один рул будет несколько действий + если это будет "однородный" процесс это будет логичнее смотреться

RasMisha
Maxim Elets
И в чем будет проблема? email это одно, апдейт филда это второе

То что на один рул будет несколько действий + если это будет "однородный" процесс это будет логичнее смотреться

Вот серьезно, у меня был опыт wfr + fu. я исходя из опыта говорю,что это *опа. а судя по твоим постам, ты говоришь что так будет логичнее смотреться. и все?

Maxim Elets
Вот серьезно, у меня был опыт wfr + fu. я исходя из опыта говорю,что это *опа. а судя по твоим постам, ты говоришь что так будет логичнее смотреться. и все?

Так ты скажи в чем эта Ж

Maxim Elets
RasMisha
ну допустим так, а теперь резко меняем задачу на email alert

ну так в чем проблема

делай вфр + алерт

тут стоит конкртная задача, а не допустим, меняем, и тд

Да, задача поставлена конкретно - именно филд апдейт.
Не раз доводилось мне слышать точку зрения, и от самих форсовцев (я имею в виду различные презентации, tutorials и пр.), что тут как нельзя лучше подойдёт стандартный функционал в любой ситуации, когда он может с этим справиться. Но тогда бы вопрос не был с подвохом :-) А расставить точки над i поможет "Triggers and Order of Execution" (привожу в сокращении главные для этого топика пункты, номера соответсвуют очереди выполнения):

...
3. Executes all before triggers.
...
7. Executes all after triggers.
...
10. Executes workflow rules.
11. If there are workflow field updates, updates the record again.
...
13. If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules are not run again.

Таким образом имеем, что при наличии сколь-нибудь "тяжелой" логики в before/after update триггерах (а это 90% если не больше всех случаев), да и в случаях когда этот field update может выполнится на insert, маленький Давид созданный point-and-click'ом может разбудить большущего Голиафа, спящего в apex trigger'ах. Вот и получается что Дмитрий не так уж не прав с apex'ом.
Моя версия такова, что в случае когда на объекте уже есть триггер в 99% лучше внести этот field update туда, особенно если там уже есть field update, с которыми стандартные средства не позволили справиться.

Это (наличие триггера), кстати, тоже уточнение.
Наличие тяжелой логики в триггерах тоже считаю не очень хорошей практикой.

11,13 пункты как бы логичны (нет, разве?) и логично тяжелый триггер писать учитывая это?
Не был бы против примера (гипотетического).

RasMisha
Это (наличие триггера), кстати, тоже уточнение.
Наличие тяжелой логики в триггерах тоже считаю не очень хорошей практикой.

Под "триггером" подразумевается просто логика вынесенная в apex code - связка Trigger + Apex Code, не куча кода в самом теле триггера, с точки зрения ООП всё может быть идеально.

RasMisha
11,13 пункты как бы логичны (нет, разве?) и логично тяжелый триггер писать учитывая это?
Не был бы против примера (гипотетического).

Пункты логичны, но про это не всегда помнят и сути это не меняет - field update запускает триггера.
Ну а вот и пример, вполне себе даже не гипотетический:
1. Первый requirement: на сохранение Opportunity в случае если Deal_Status__c changed to "Approved" произвести сложный поиск по базе (сделать n SOQL запросов) и обновить например (k DML операций) Contact какой-нибудь - без Apex'а и соответствующего триггера никак

Прошло 3 месяца с тех пор как выполнен 1-ый requirement и поступает второй:
2. Если при сохранении Opportunity Amount < 10K, автоматически Deal_Status__c ставить в "Approved" - вроде ничего сложного и имплементируется через point-and-click и field update.

А теперь у нас идёт insert двух Opportunity - в одном Deal_Status__c сразу "Approved", а у второго Amount - 5K. На выходе имеем - сложный поиск из n SOQL запросов выполнится дважды - первый раз для Opportunity со статусом "Approved", а второй раз когда второму Opportunity поменяется статус на "Approved", т.к. у него Amount < 10K, то же самое и с DML.

В итоге имеем 2n SOQL операций и 2k DML. И да, такое в жизни случается на более реальных примерах.

Уважаемые, не забывайте про нижние эдишны сэйлсфорса (Group, Professional), где триггеры/классы вообще нельзя создавать, они там только в составе пакета работают.
http://www.salesforce.com/us/developer/docs/packagingGuide/Content/dev_packages_apex_ge_pe.htm

А чего про них забывать - разработчики там не нужны. Я по крайней мере туда не пойду.
Пусть клиент сам галочки гоняет.
Если клиент этого не умеет и не понимает в чем разница между Professional и Enterprise то рано или поздно придет задача которою галочками не решишь, а заказчик будет не тебя смотреть и говорить "тыж программист".

Только код, только хардкор.
Лично я не люблю мышкотыцкать, а люблю код писать. Люблю когда все в одном месте и не надо разыскивать где и что включает и переключает.
Хотя :-) Если есть возможность сделать какой-то функционал мышкотыцкальством, делаю именно так ибо... по Феншую. СФному Феншую.

ilya leshchuk
Под "триггером" подразумевается просто логика вынесенная в apex code - связка Trigger + Apex Code, не куча кода в самом теле триггера, с точки зрения ООП всё может быть идеально.

Да причем тут вынесен он или нет? Я про то что наличие триггера (не важно через что он выполняется) с "тяжелым" кодом это уже уточнение, которое было опущено.

Ну и тут вопрос у меня возникает по поводу сколько вы можете себе позволить soql/dml операций в триггере? Еще и триггер для стандартного объекта =/

RasMisha
ilya leshchuk
Под "триггером" подразумевается просто логика вынесенная в apex code - связка Trigger + Apex Code, не куча кода в самом теле триггера, с точки зрения ООП всё может быть идеально.

Да причем тут вынесен он или нет? Я про то что наличие триггера (не важно через что он выполняется) с "тяжелым" кодом это уже уточнение, которое было опущено.

Ну не мог же я сразу все карты на стол выложить, тогда бы не было такого подвоха, хотя можно было бы топик назвать "В каких случаях лучше использовать WF + FU, а в каких Apex Trigger?"

RasMisha
Ну и тут вопрос у меня возникает по поводу сколько вы можете себе позволить soql/dml операций в триггере? Еще и триггер для стандартного объекта =/

Я считаю что ответ здесь простой - я могу позволить себе минимально возможное кол-во SOQL/DML операций, необходимое для реализации поставленной задачи. Да, надо делать код оптимальным, но будь он хоть трижды bulkified и четырежды выдержан во всех best practices, если надо сделать DML операцию или SOQL запрос - от этого никуда не уйти. А вот если оптимальная реализация нового бизнес требования приводит к тому что в совокупности с уже существующими операциями мы отхватываем горячо любимый limit exception - пора рефакторить и оптимизировать всё в совокупности.

yurybond
Уважаемые, не забывайте про нижние эдишны сэйлсфорса (Group, Professional), где триггеры/классы вообще нельзя создавать, они там только в составе пакета работают.
http://www.salesforce.com/us/developer/docs/packagingGuide/Content/dev_packages_apex_ge_pe.htm

Писать managed packages для PE это такой геморрой, особенно если это под конкретного заказчика, а не generic package, что по-моему заказчику будет дешевле перейти на более "высокий" план.

Interesting information? Help us, post link to social media..