Недостатки Force.com платформа [закрыто]

Я вижу, что вы получили некоторые ответы, но я хотел бы повторить, сколько времени тратится на то, чтобы обойти различные ограничения губернатора на платформе. Как бы мне ни нравилась платформа на определенных уровнях, я бы очень сильно, высоко, решительно рекомендовал ее в качестве общей платформы разработки приложений. Это здорово, как супер настраиваемый и расширяемый CRM-приложение, если это то, что вы хотите. В то время как их маркетинга является исключительным в продвижении идеи Force.com в целом платформа разработки, это даже не близко еще.

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

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

чтобы дать вам простое представление о том, как разработчик не дружелюбен к окружающей среде, возьмите "отсутствие среды отладки", о которой говорилось выше. Все гораздо хуже. В журналах отладки можно увидеть только до 20 последних запросов к серверу. Итак, когда вы разрабатываете внутри приложения, вам нужно создать" новый " запрос отладки, выберите свое имя, нажмите "Сохранить", вернитесь к своему приложению, обновите страницу, перейдите на вкладку" отладка", попробуйте найти запрос, в котором будет размещен ваш журнал отладки, нажмите "Найти", чтобы найти текст, который вы ищете. Это как десять кликов, чтобы посмотреть на отладочный вывод. Хотя это может показаться тривиальным, это просто пример того, как мало внимания и внимания было уделено опыту разработчика.

все, что касается платформы разработки, является привитой запоздалой мыслью. Это замечательно за то, что он есть, но в целом Пита по большей части. Если вы не знаете точно, что вы делаете (например, вы сертифицированы и имеете очень близкое понимание Apex), это легко займет у вас более 10-20 раз больше времени, чем в другой среде, чтобы сделать что-то, что кажется смехотворно простым, если вы вообще можете добиться успеха.

ограничения губернатора действительно так плохи. У вас есть комбинация различных ограничений (запросы к базе данных, возвращаемые строки, "операторы сценария", будущие вызовы, выноски и т. д.) и вы должны знать ровно что вы делаете, чтобы избежать этих. Например, если у вас есть вычисленное поле свертки "формула" для объекта и у вас есть триггер для дочернего объекта, он выполнит триггеры родительского объекта и подсчитает их по вашим ограничениям. Такие вещи не очевидны, пока вы не пройдете через болезненный процесс попыток и неудач.

вы будете пытаться одну вещь, чтобы избежать одного предела, и ударил другой в бесконечной игре "ударить предел". В процессе вам придется кардинально перепроектировать все ваше приложение и подход, а также переписать весь ваш тестовый код. Ты должны есть 75% тестового покрытия кода для развертывания в производстве, что на самом деле очень хорошо, но в сочетании со всеми другими ограничениями, это очень обременительно. Вы действительно попадете в пределы губернатора, написав свой тестовый код, который не будет появляться в обычных пользовательских сценариях, но это помешает вам достижение охвата.

Это не говоря уже о целом ряде других вопросов. Упаковка не то, что вы ожидаете. Вы не можете упаковать приложение и доставить его пользователям без значительного вмешательства пользователя и настройки со стороны администратора организации. AppExchange-это полная шутка, и они даже начали заряжать 5K, чтобы получить ваше приложение в списке. Импорт с загрузчиком данных отстой, особенно если у вас есть какие-либо триггеры. Вы не можете экспортировать все ваши данные в одном шаг, который включает ваши отношения таким образом, что он может быть легко повторно импортирован в другую организацию за один шаг (например, dev org). Вы можете обновлять песочницу только один раз в месяц из производства, без исключений, и вы не можете включать свои данные в обновление по умолчанию, если вы не вызвали своего руководителя учетной записи, чтобы разблокировать эту функцию. Вы не можете массово удалять данные в пользовательских объектах. Вы не можете изменить имя пакета. Некоторые вещи могут принимать многочисленные дней to завершите после того, как вы запросили их, например, резервную копию данных, прежде чем вы хотите развернуть приложение, без отчета о ходе выполнения по пути и не очень много смысла, когда именно произошел экспорт. Учитывая, что существуют проблемы синхронности данных, если есть отношения между данными, существуют серьезные проблемы целостности данных в том, что нет такой вещи, как "транзакция", которая может экспортировать многочисленные объекты за один шаг. Вероятно, есть некоторые коммерческие инструменты для облегчения некоторых из них, но они не досягаемы для обычных разработчиков, которые не могут иметь огромный бюджет.

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

Я не хочу быть настолько негативным, потому что платформа очень крута в некоторых отношениях, и они пытаются делать вещи в мультитенантной среде, которые никто больше не делает. Это очень инновационная среда и мощная на некоторых уровнях (мне действительно нравится VisualForce много), но дайте ему еще год или два. Они сотрудничают с VMware, возможно, это приведет к тому, что разработчики получат немного больше манежа, а не тюремную камеру для работы.

вот несколько вещей, которые я могу дать вам, проведя довольно много времени на платформе в последние две недели или около того:

1. там нет RESTful API. У них есть API на основе soap, который вы можете вызвать, но нет способа сделать истинные вызовы restful

2. там нет простой способ, чтобы забрать их предметами и конвертировать их в объекты JSON.

3. страницы визуальной силы в порядке, пока вы не захотите их настроить и тогда это целый мир боли.

4. страницы визуальной силы должны быть привязаны к SObjects в противном случае нет способа получить стандартные поля ввода, такие как datepicker или select list для работы.

5. плагин eclipse в порядке, если вы хотите работать самостоятельно, но если вы хотите работать в большой команде с плагином eclipse забудьте об этом. Он не обрабатывает синхронизацию с сервером и с сервера, он падает, и это не очень полезно все.

6. НЕТ НИКАКОГО ОТЛАДЧИКА! Если вы хотите отлаживать, это буквально отладка системой.отладочные операторы. Это, вероятно, самая большая проблема, которую я нашел

7. их модель " MVC " на самом деле не MVC. Это намного ближе к ASP.NET веб-формы. Ваши взгляды тесно связаны не только с моделями, но и с контроллерами.

8. хранение большого количества документов не представляется возможным. Нам нужно хранить более 100 Гб документов и нам процитировали какую-то нелепую цифру. Мы решили реализовать наше хранилище документов на инфраструктуре amazons S3

9. даже если язык основан на java, это не java. Вы не можете импортировать внешние пакеты или библиотеки. Кроме того, доступные базовые библиотеки сильно ограничены, поэтому мы обнаружили, что реализуем кучу вещей извне, а затем выставляем эти биты в качестве служб, которые вызываются force.com

10. вы можете вызов внешних служб SOAP или REST, но тело сообщения ограничено 100 Кб, поэтому оно очень ограничено в том, что вы можете вызвать.

во всей честности, пока потенциальные преимущества к превращаться на что-то как force.com платформа, для меня, вы не могли использовать force.com платформа для истинных приложений корпоративного уровня. В лучшем случае вы могли бы написать некоторые основные приложения в стиле crud, но как только вы перейдете во что-то отдаленно сложное, я буду избегать этого, как чума.

Вау-здесь много чего, о чем я даже не знал, были ограничения - после работы на платформе в течение нескольких лет.

но просто добавить некоторые другие вещи...

причина, по которой у вас нет построчного отладчика, заключается именно в том, что это мультитенантная платформа. По крайней мере, это то, что говорит SFDC - похоже, что в этот век богатого потоками программирования это не оправдание, но это, по-видимому, причина. Если вам нужно написать код, у вас есть "Система.debug (String) " как ваш отладчик - я помню, что у меня были более сложные инструменты отладки сервера в Java 1.2 около 12 лет назад.

еще одна вещь, которую я действительно ненавижу в системе, - это контроль версий. Spring framework не используется для того, для чего обычно используется Spring - это действительно больше инструмент настройки в SFDC, а не контроль версий. Параметре sfdc обеспечивает нулевой вариант-контроль.

вы можете застрять на несколько дней делать то, что должно казаться так смехотворно легко, например, планирование отчета SFDC для экспорта в файл CSV и электронной почты в список получателей... Ну, о самом простом способе сделать это-создать пользовательский объект с пользовательским полем, с бизнес-правилом и шаблоном электронной почты Visualforce... а затем для кода вам нужно написать компонент Visualforce, который передает данные отчета в шаблон электронной почты Visualforce в качестве вложения, и вы пишете анонимное поле Apex code schedule-обновление пользовательского объекта... Для параметре sfdc разработчики, это практически ежедневная задача... пытаясь собрать вместе около пяти различных технологий для выполнения задач, которые кажутся такими простыми.... И это может вызвать головные боли управления и напряженность тоже-как правило, вы обнаружите это после получения предложения сделать что-то, что не работает в пользовательском сообществе (как кто-то уже сказал), а затем попробовать много вещей, которые после их разработки вы обнаружите, что они просто не работают по какой-то странной причине-например, "вы не можете запланировать VisualForce страница", или" вы не можете вызвать getContent из планируемого контекста " или по какой-либо другой тайной причине.

есть так много, много сводящих с ума маленьких gotcha's на платформе SFDC, что как только вы знаете, почему они там, это имеет смысл... но это все еще очень плохие ограничения, которые мешают вам делать то, что вам нужно. Вот некоторые из моих;

1. вы не можете получить информацию о владельце записи "из коробки" на практически любой записи - вы должны написать триггер, который связывает владельца при создании записи с записью, которую вы вставляете. Зачем? Короткий ответ, потому что владелец может быть либо "человеком", либо "очередью", и эти два совершенно разные сущности... Имеет смысл, но это может перевернуть проект буквально с ног на голову.

2. сводящая с ума модель безопасности. Пример: разрешение" управление публичными отчетами "значительно отличается от" создание и настройка отчетов", и это в основном касается всего на платформе... особенно папки любого рода.

3. Как уже упоминалось, поддержка в принципе не существовало. Если вы чрезвычайно самодостаточный человек, или имеете много ресурсов SFDC, или имеете много времени и/или очень снисходительный менеджер, или отвечаете за систему SFDC, которая работает нормально, вы находитесь в довольно хорошей форме. Если вы не находитесь ни в одном из этих положений, вы можете оказаться в глубокой беде.

SFDC-очень соблазнительный бизнес утверждение... отсутствие оборудования, довольно хорошая безопасность, фиксированная цена, отсутствие инфраструктуры, и вы получаете веб-CRM с пакетной и schedualble обработкой... Но, как говорили другие плакаты, это действительно довольно быстрый рост в обучении развитию, и если вы идете с консалтингом, я думаю, что самая низкая цена, которую я видел, была $200/час.

Salesforce имеет тенденцию интегрироваться с другими вещами через несколько лет после того, как некоторые технологии становятся общим местом-JSON и jquery приходят на ум... и если у вас есть другие общие инфраструктуры, с которыми вы хотите сделать интеграцию, например JIRA, рассчитывают заплатить много больше, и они могут быть довольно глючными.

и как упоминалось в одном из других плакатов, вы постоянно боретесь с ограничениями губернатора, которые могут просто свести вас с ума... вложение не может быть > 5 Мб. Период. И иногда

Мне очень, очень нравится платформа, но поверьте мне - это может быть одна очень жестокая дама.

но справедливости ради SFDC, я бы сказал так: самая большая проблема, которую я нахожу с платформой, - это не сама платформа, а гигантские ожидания, которые почти каждый, кто видит платформу, но не развился на ней.... и эти люди, как правило, находятся на позициях большого авторитета в бизнес-организациях; маркетинг, сбывания, управление, etc. Огромные разъединения происходят, и головы катятся или угрожают катиться ежедневно-все потому, что есть эта отличная платформа со странными gotchas и тысячами людей, изо всех сил пытающихся каждый день понять, почему все должно просто работать, когда они просто этого не делают и не будут.

EDIT:
Просто добавьте к комментариям lomaxx о MVC; в терминологии SFDC это тесно связано с тем, что известно как "viewstate" - A и это может быть действительно багги, в этом что находится на странице VF-это не что находится в классе контроллера для страницы. Таким образом, вы должны пройти через странные вращения, чтобы синхронизировать то, что на странице с тем, что контроллер собирается писать в SF, когда вы нажимаете кнопку "Сохранить" (или делаете свой http-выноску или что-то еще).... чувак, это раздражает.

Я думаю, что другие люди более подробно рассмотрели недостатки, но мне кажется, что он вообще не использует парадигму MVC или поддерживает много способов повторного использования кода. Делать что-либо помимо простых приложений-это упражнение в разочаровании по сравнению с разработкой приложения с использованием чего-то вроде ASP.Net MVC.

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

Я думаю, что как CMS это довольно круто, но как платформа для приложений без CMS, это не имеет смысла для меня.

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

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

еще хуже ответ от технической поддержки "попробуйте действие, и если есть исключение, поймайте его"

учитывая Force.com это "облачная" платформа, ее способность выступать в качестве клиента для внешней службы, определяемой WSDL, довольно не впечатляет. См.http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ за то, что вы могли бы в конечном итоге сделать.

ко всему вышесказанному мне любопытно, как выпускается VMforce, позволяющий Java программисту писать код для Force.com, изменяет недостатки выше?

http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071

Я думаю, они пытаются решить эти проблемы. В dreamforce они упомянули, что мы пытаемся снизить ограничения губернатора только до 4. Я не уверен в деталях. У них есть REST API для раннего доступа, и они купили heroku, который является разработкой ruby в облаке. Они разделили базу данных, с помощью database.com таким образом, вы можете делать все свои веб-разработки и вызовы БД с помощью database.com.

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