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