В даний час ми розглядаємо використання платформи Force.com як нашої платформи для розробки, а хлопці з продажу та веб-сайт force.com повні причин, чому це найкраща платформа у світі. Однак я шукаю кілька реальних недоліків використання такої платформи.
Відповіді:
Ось 10 для початку.
Застереження / розкриття інформації: Існує безліч переваг від розміщеної платформи, наприклад force.com. Force.com регулярно вдосконалює платформу. У ньому є багато речей, які мені подобаються. Я заробляю гроші, будуючи на force.com
Я бачу, що ви отримали кілька відповідей, але я хотів би ще раз наголосити, скільки часу витрачається на обхід різних обмежень губернатора на платформі. Наскільки мені подобається платформа на певних рівнях, я б дуже наполегливо, наполегливо рекомендував не рекомендувати її як загальну платформу для розробки додатків. Це чудово, як супер налаштовується та розширювана програма CRM, якщо це те, що ви хочете. Незважаючи на те, що їх маркетинг є винятковим, просуваючи ідею Force.com як загальної платформи для розвитку, це ще навіть далеко не близько.
Ефективність стабільної платформи та уникнення великих проблем із продуктивністю та стабільністю легко витратити, намагаючись кодувати обмеження, на які посилаються люди. Платформа має стільки обмежень, що вона стає абсолютно божевільною. Ці обмеження не є висококласними обмеженнями, які ви досягнете, коли у вас буде багато користувачів, ви досягнете їх майже відразу.
Хоча зазвичай є методи їх обійти, дуже важко з’ясувати стратегії їх уникнення, тоді як ви також намагаєтесь розробити бізнес-логіку вашого власного додатку.
Щоб дати вам просте уявлення про те, наскільки несприятливим для розробників є середовище, візьміть "відсутність середовища налагодження", згадану вище. Це гірше за це. Ви можете побачити до 20 останніх запитів до сервера у журналах налагодження. Отже, коли ви розробляєте програму, вам потрібно створити запит на налагодження "Новий", вибрати своє ім'я, натиснути "Зберегти", повернутися до програми, оновити сторінку, клацнути назад на вкладці налагодження, спробувати знайти запит, в якому буде розміщено ваш журнал налагодження, натисніть "знайти" для пошуку тексту, який ви шукаєте. Це схоже на десять клацань, щоб переглянути вихід налагодження. Хоча це може здатися дрібницею, це лише приклад того, як мало уваги та уваги було приділено досвіду розробника.
Все, що стосується платформи для розробки, - це прищеплене додаткове мислення. Це чудово тим, що воно є, але загальним ПДФО здебільшого. Якщо ви точно не знаєте, що робите (як, наприклад, ви сертифіковані і дуже глибоко розумієте Apex), це легко забере у вас більше 10-20 разів часу, який було б в іншому середовищі робити щось таке, що здається смішним простим, якщо ти взагалі можеш досягти успіху.
Обмеження губернатора справді такі погані. У вас є комбінація різних обмежень (запити до бази даних, повернені рядки, "виписки сценаріїв", майбутні дзвінки, виноски тощо), і ви повинні точно знати , що ви робите, щоб уникнути цього. Наприклад, якщо у вас є розраховане зведене поле "формула" на об'єкті, і у вас є тригер на дочірньому об'єкті, він виконає тригери батьківського об'єкта і зарахує їх до ваших обмежень. Такі речі не очевидні, поки ви не пройдете болісний процес спроб і невдач.
Ви спробуєте одне, щоб уникнути одного ліміту, а вдарите інше у нескінченній грі "Whack a limit". У процесі вам доведеться кардинально переробити весь ваш додаток і підхід, а також переписати весь свій тестовий код. Ви повинні мати 75% охоплення тестовим кодом для розгортання у виробництві, що насправді дуже добре, але в поєднанні з усіма іншими обмеженнями це дуже обтяжливо. Ви фактично досягнете обмежень губернатора, написавши свій тестовий код, який не з’явиться у звичайних сценаріях користувача, але це завадить вам досягти покриття.
Це не кажучи вже про цілу низку інших питань. Упаковка - це не те, що ви очікуєте. Ви не можете упакувати програму та доставити її користувачам без значного втручання та налаштування користувача з боку адміністратора організації. AppExchange - це жарт, і вони навіть почали заряджати 5K, лише щоб перерахувати ваш додаток. Імпорт за допомогою завантажувача даних відстійний, особливо якщо у вас є тригери. Ви не можете експортувати всі свої дані за один крок, що включає ваші відносини, таким чином, що їх можна легко повторно імпортувати в іншу організацію за один крок (наприклад, організацію розробника). Ви можете оновлювати пісочницю лише раз на місяць з моменту виробництва, без винятків, і ви не можете включити свої дані в оновлення за замовчуванням, якщо ви не зателефонували керівнику свого облікового запису, щоб цю функцію розблокували. Ти можеш' t масове видалення даних у користувацьких об'єктах. Ви не можете змінити імена пакетів. Деякі речі можуть зайняти численніднів до завершення після того, як ви їх запитуєте, наприклад, резервного копіювання даних перед тим, як ви захочете розгорнути програму, без звіту про хід роботи та не надто відчуваючи, коли саме відбувся експорт. Враховуючи, що існують проблеми синхронності даних, якщо між даними існують взаємозв'язки, є серйозні проблеми цілісності даних, оскільки не існує поняття "транзакція", яке може експортувати численні об'єкти за один крок. Можливо, є деякі комерційні інструменти, які полегшують це, але вони не доступні звичайним розробникам, які можуть не мати величезного бюджету.
Все інше, про що інші люди говорили тут, є правдою. Щоб зберегти файл, іноді може знадобитися від п’яти секунд до хвилини.
Я не маю на увазі бути настільки негативним, тому що платформа в чомусь дуже крута, і вони намагаються робити те, що робиться в середовищі з декількома орендарями, чого не робить ніхто інший. Це дуже інноваційне середовище та потужне на деяких рівнях (мені насправді дуже подобається VisualForce), але дайте йому ще рік-два. Вони співпрацюють з VMware, можливо, це призведе до того, що розробники отримають трохи більше манежу, а не тюремної камери для роботи.
Ось декілька речей, які я можу дати вам, витративши чималий час на розробку на платформі за останні два тижні:
Немає RESTful API. У них є API на основі мила, до якого ви можете зателефонувати, але неможливо здійснити справжні спокійні дзвінки
Немає простого способу взяти їхні SObjects і перетворити їх в об'єкти JSON.
Сторінки із зоровою силою працюють, поки ви не захочете їх налаштувати, і тоді це цілий світ болю.
Сторінки Visual force повинні бути прив'язані до SObjects, інакше немає можливості отримати стандартні поля введення, такі як піктограма дати або вибраний список для роботи.
Плагін eclipse - це нормально, якщо ви хочете працювати самостійно, але якщо ви хочете працювати у великій команді з плагіном eclipse, забудьте про це. Він не обробляє синхронізацію із сервером і з нього, він аварійно завершує роботу, і це насправді зовсім не корисно.
НЕМАЄ ДЕБАГЕРА! Якщо ви хочете налагодити, це буквально налагоджено операторами system.debug. Це, мабуть, найбільша проблема, яку я знайшов
Їхня модель "MVC" насправді не є MVC. Це набагато ближче до веб-форм ASP.NET. Ваші погляди тісно пов'язані не тільки з моделями, але і з контролерами.
Зберігання великої кількості документів неможливе. Нам потрібно зберігати понад 100 ГБ документів, і нам вказали якусь смішну цифру. Ми вирішили впровадити наше зберігання документів на інфраструктурі amazons S3
Навіть якщо мова заснована на Java, це не Java. Ви не можете імпортувати будь-які зовнішні пакунки або бібліотеки. Крім того, доступні базові бібліотеки суворо обмежені, тому ми виявили, що реалізуємо купу речей зовні, а потім виставляємо ці біти як послуги, які викликаються force.com
Ви можете зателефонувати до зовнішніх служб на основі SOAP або REST, але тіло повідомлення обмежене 100 кб, тому це дуже обмежує те, що ви можете зателефонувати.
Чесно кажучи, хоча, маючи потенційні вигоди від розвитку на чомусь на кшталт платформи force.com, для мене ви не можете використовувати платформу force.com для справжніх програм на рівні підприємства. У кращому випадку ви могли б написати декілька основних додатків для грубого стилю, але як тільки ви перейдете до чогось віддалено складного, я б уникав цього, як чуми.
Вау - тут є багато такого, про що я навіть не підозрював, що це обмеження - після роботи на платформі протягом декількох років.
Але просто щоб додати деякі інші речі ...
Причина, по якій у вас відсутній підрядковий налагоджувач, полягає саме в тому, що це платформа для кількох орендарів. Принаймні так говорить SFDC - здається, що в цей вік багатопоточного програмування це не є великим виправданням, але це, мабуть, причина. Якщо вам доводиться писати код, у якості налагоджувача ви використовуєте "System.debug (String)" - я пам'ятаю, що в Java 1.2 існували більш досконалі інструменти налагодження сервера близько 12 років тому.
Ще одна річ, яку я дуже ненавиджу в системі - це контроль версій. Фреймворк Spring не використовується для того, для чого зазвичай використовується Spring - це дійсно більше, ніж інструмент конфігурації в SFDC, а не контроль версій. SFDC забезпечує нульовий контроль версій.
Ви можете затриматись на кілька днів, роблячи щось, що може здатися настільки смішно простим, як, скажімо, планування звіту SFDC для експорту до файлу CSV та надсилання електронного листа до списку одержувачів ... Ну, про найпростіший спосіб це зробити створити власний об'єкт із власним полем, з правилом робочого циклу та шаблоном електронної пошти Visualforce ... а потім для коду потрібно написати компонент Visualforce, який передає дані звіту до шаблону електронної пошти Visualforce як вкладення, і ви пишете анонімний APEX оновлення польового розкладу користувацького об'єкта ... Для розробників SFDC це майже щоденне завдання ... намагання об'єднати близько п'яти різних технологій для виконання завдань, які здаються настільки простими .... І це може спричинити головний біль в управлінні і напруга теж - як правило, ви це дізнаєтесь, отримавши пропозицію зробити щось, що нет працювати в спільноті користувачів (як хтось уже сказав), а потім спробувати багато речей, які після того, як ви їх розробили, виявили б, що вони просто не працюють з якоїсь дивної причини - наприклад, "ви не можете запланувати Сторінка VisualForce ", або" ви не можете зателефонувати getContent із запланованого контексту "або іншої прихованої причини.
На платформі SFDC є так багато, багато божевільних дрібниць, що коли ти знаєш, ЧОМУ вони там, це має сенс ... але вони все ще дуже погані обмеження, які заважають тобі робити те, що тобі потрібно робити. Ось деякі мої;
Ви не можете отримати інформацію про власника запису "з коробки" майже на будь-якому записі - вам потрібно написати тригер, який зв'язує власника при створенні запису із записом, який ви вставляєте. Чому? Коротка відповідь, оскільки власник може бути або "людиною", або "чергою", і ці два є кардинально різними особами ... Має сенс, але це може перевернути проект буквально з ніг на голову.
Моторошна модель безпеки. Приклад: Дозвіл "Управління загальнодоступними звітами" значно відрізняється від дозволу "Створювати та налаштовувати звіти", і це в основному стосується всього на платформі ... особливо папок будь-якого типу.
Як уже зазначалося, підтримка в основному відсутня. Якщо ви надзвичайно самодостатня особа, або у вас багато ресурсів SFDC, або у вас багато часу та / або дуже пробачуючий менеджер, або ви відповідаєте за систему SFDC, яка працює нормально, ви в досить хорошому стані форму. Якщо ви не знаходитесь в жодному з цих положень, ви можете потрапити в глибоку біду.
SFDC - це дуже спокуслива пропозиція для бізнесу ... відсутність розміщення обладнання, досить хороша безпека, фіксована ціна, відсутність інфраструктури, І ви отримуєте веб-CRM з можливістю пакетної та графічної обробки ... Але, як говорили інші афіші, це справді ціле нарощування в навчанні для розвитку, і якщо ви йдете за консультацією, я думаю, що найнижча ціна, яку я бачив, була 200 доларів на годину.
Salesforce, як правило, інтегрується з іншими речами через роки після того, як деякі технології стають звичними - JSON і jquery приходять на розум ... і якщо у вас є інші спільні інфраструктури, з якими ви хочете зробити інтеграцію, наприклад, JIRA, розраховуйте на додаткову плату, і вони можуть бути досить глючними.
І як один із інших згаданих плакатів, ви постійно боретеся з обмеженнями губернатора, які можуть просто звести вас з розуму ... вкладення НЕ може бути більше> 5 Мб. Період. І іноді <3 МБ (якщо закодовано base64). Десять виносок HTTP у класі. Період. Існують десятки опублікованих обмежень губернатора, і багато з них не є такими, які ви, безсумнівно, знайдете і просто хочете з криком вибігти зі свого офісу.
Мені справді дуже подобається платформа, але повірте мені - це може бути одна справді жорстока коханка.
Але справедливості заради SFDC я б сказав наступне: найбільша проблема, яку я знаходжу з платформою, - це не сама платформа, а гігантські очікування, які має майже кожен, хто бачить платформу, але не розвинувся на ній .... і ці люди, як правило, займають позиції великого авторитету в бізнес-організаціях; маркетинг, продажі, управління і т. д. Величезні відключення трапляються, і голови котяться, або їм загрожує щодня - все тому, що там є ця чудова платформа з дивною ситуацією, і тисячі людей щодня намагаються розібратися, чому речі просто повинні працювати вони просто не роблять і не будуть.
EDIT:
Просто додати до коментарів lomaxx про MVC; У термінології SFDC це тісно пов'язано з тим, що відоме як "viewstate" - і це може бути справді глючним, оскільки те, що знаходиться на сторінці VF, не є тим, що є в класі контролера для цієї сторінки. Отже, вам доведеться пройти дивні обертання, щоб синхронізувати те, що на сторінці, з тим, що контролер збирається писати в SF, коли ви натискаєте кнопку "зберегти" (або робите свою додаткову інформацію про HTTP або що завгодно) .... чоловіче, це дратує .
Я думаю, що інші люди більш глибоко висвітлювали недоліки, але для мене це, здається, не використовує парадигму MVC або не підтримує багато способу повторного використання коду взагалі. Робити що-небудь, окрім простих програм, - це розчарування в порівнянні з розробкою програми, що використовує щось на зразок ASP.Net MVC.
Крім того, інструменти, рівень даних та розчарування спроби рефакторингу коду або перейменування полів у процесі розробки не допомагають.
Я думаю, що як система управління вмістом це досить круто, але як платформа для додатків, що не містять системи управління, для мене це не має сенсу.
Модель безпеки також дуже обмежує ... але це не найгірша частина. Наразі ви не можете стверджувати, чи має користувач можливість виконати певну дію.
Ви можете перевірити, яка їхня роль, але не можете перевірити, чи має ця роль дозволи на виконання поточної дії.
Ще гірша реакція технічної підтримки на те, що "спробуй дію, і якщо є виняток, злови"
Враховуючи, що 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, який є рубіновою розробкою в хмарі. Вони розподілили базу даних за допомогою database.com, щоб ви могли робити всю свою веб-розробку та дзвінки на базі даних за допомогою database.com.
Думаю, вони намагаються зробити це якомога агностичнішим. Але зараз це всі оголошення та ранній доступ, тому, як і їхні заяви про «Безпечну гавань», не купуйте те, що вони говорять, а лише те, що вони зараз мають.