Inconvénients de la plateforme Force.com
Nous envisageons actuellement d'utiliser la plate-forme Force.com comme plate-forme de développement et les vendeurs et le site Web force.com regorgent de raisons pour lesquelles c'est la meilleure plate-forme au monde. Ce que je recherche, cependant, c'est de réels inconvénients à utiliser une telle plate-forme.
Voici 10 pour vous aider à démarrer.
- Apex est un langage propriétaire. À part le plugin Eclipse force.com, il y a peu ou pas d'outils disponibles tels que le refactoring, l'analyse de code, etc.
- Apex a été modélisé sur Java 5, qui est considéré comme étant en retard par rapport aux autres langages, et sans outillage (voir # 1), peut être assez lourd.
- Le déploiement est encore assez manuel avec de nombreux accrochages et étapes manuelles. Cette situation s'améliore lentement avec le temps, mais vous serez déçu si vous avez l'habitude d'avoir des déploiements automatisés.
- Apex manque de packages/espaces de noms. Toutes vos classes, interfaces, etc. vivent dans un dossier sur le serveur. Cela rend le code beaucoup moins organisé et les noms de classe/interface nécessairement longs pour éviter les conflits de noms et pour fournir le contexte. C'est l'une de mes plus grosses plaintes, et je ne choisirais pas librement de construire sur force.com pour cette seule raison.
- Le "force.com IDE", alias force.com Eclipse plugin, est incroyablement lent. L'enregistrement d'un fichier, qu'il s'agisse d'un fichier de classe, d'un fichier texte, etc., prend généralement au moins 5 secondes et parfois jusqu'à 30 secondes selon le nombre d'objets, les types de données, les fichiers de classe, etc. dans votre organisation. L'enregistrement est également une action de blocage, nécessitant non seulement une compilation, mais une synchronisation complète de votre projet local avec le serveur. Ordres de grandeur plus lents que Java ou .NET.
- La communauté des développeurs en ligne ne semble pas très saine. J'ai remarqué que de nombreux messages sur le forum sont restés sans réponse ou non résolus. Je pense que cela peut avoir quelque chose à voir avec le logiciel de forum utilisé par salesforce.com, qui semble assez dur.
- L'accès DSL aux données dans Apex laisse beaucoup à désirer. Ce n'est même pas à distance compétitif avec les goûts de (N) Hibernate, JPA, etc.
- Le développement d'une application sur Apex/VisualForce est un exercice d'ingénierie des limites du gouverneur. La moitié du temps du programmeur est facilement passée à essayer d'optimiser pour éviter les nombreuses limites du gouverneur et d'autres problèmes comme les limites d'état de visualisation de Visualforce. On pourrait faire valoir que si vous écrivez du code efficace pour commencer, vous n'aurez pas ce problème, ce qui est vrai dans une certaine mesure. Cependant, il y a de nombreuses fois que vous avez des raisons valables de faire plus de x requêtes dans une session, ou de parcourir plus de x enregistrements, etc.
- Le cycle save-> compile-> run est extrêmement lent, esp. lorsqu'il s'agit de compresser et de télécharger l'intégralité du groupe de ressources statiques juste pour faire quelque chose comme tester une modification CSS ou javascript mineure.
- En général, la douleur d'une jeune plate-forme naissante sans les avantages qu'elle soit open source. Vous n'avez aucun moyen de valider et/ou de corriger des bogues dans la plateforme. Ils disent de le publier sur leur IdeaExchange. Oui, bonne chance avec ça.
Avertissements/Divulgations: Il existe de nombreux avantages pour une plate-forme hébergée telle que force.com. Force.com améliore régulièrement la plateforme. Il y a plein de choses que j'aime. Je gagne de l'argent en construisant sur force.com
Je vois que vous avez obtenu quelques réponses, mais je voudrais répéter combien de temps est perdu pour contourner les différentes limites du gouverneur sur la plate-forme. Autant que j'aime la plate-forme à certains niveaux, je la déconseille fortement, fortement, en tant que plate-forme générale de développement d'applications. C'est génial comme application CRM super configurable et extensible si c'est ce que vous voulez. Bien que leur marketing soit exceptionnel pour pousser l'idée de Force.com en tant que plate-forme de développement générale, il n'est même pas encore proche à distance.
L'efficacité d'avoir une plate-forme stable et d'éviter les gros problèmes de performances et de stabilité est facilement gaspillée en essayant de coder autour des limites auxquelles les gens se réfèrent. Il y a tellement de limites à la plate-forme, elle devient complètement exaspérante. Ces limites ne sont pas des limites haut de gamme que vous atteindrez une fois que vous aurez beaucoup d'utilisateurs, vous les atteindrez presque immédiatement.
Bien qu'il existe généralement des techniques pour les contourner, il est très difficile de trouver des stratégies pour les éviter pendant que vous essayez également de développer la logique métier de votre application réelle.
Pour vous donner une idée simple de la façon dont l'environnement n'est pas convivial pour les développeurs, prenez le "manque d'environnement de débogage" mentionné ci-dessus. C'est pire que ça. Vous ne pouvez voir que jusqu'à 20 des demandes les plus récentes adressées au serveur dans les journaux de débogage. Donc, pendant que vous développez à l'intérieur de l'application, vous devez créer une "nouvelle" demande de débogage, sélectionnez votre nom, appuyez sur "Enregistrer", revenez à votre application, actualisez la page, cliquez sur votre onglet de débogage, essayez de trouver la demande qui hébergera votre journal de débogage, cliquez sur "trouver" pour rechercher le texte que vous recherchez. C'est comme dix clics pour regarder une sortie de débogage. Bien que cela puisse sembler trivial, ce n'est qu'un exemple du peu de soin et de considération accordés à l'expérience du développeur.
Tout ce qui concerne la plate-forme de développement est une réflexion après coup greffée. C'est remarquable pour ce que c'est, mais un PITA total pour la plupart. Si vous ne savez pas exactement ce que vous faites (comme vous êtes certifié et que vous avez une compréhension très approfondie d'Apex), cela vous prendra facilement plus de 10 à 20 fois le temps qu'il faudrait dans un autre environnement pour le faire quelque chose qui semble être ridiculement simple, si vous pouvez même réussir.
Les limites du gouverneur sont en effet si mauvaises. Vous avez une combinaison de diverses limites (requêtes de base de données, lignes retournées, "instructions de script", appels futurs, légendes, etc.) et vous devez savoir exactement ce que vous faites pour les éviter. Par exemple, si vous avez un champ de "formule" de cumul calculé sur un objet et que vous avez un déclencheur sur un objet enfant, il exécutera les déclencheurs d'objet parent et les comptera par rapport à vos limites. Des choses comme ça ne sont pas évidentes tant que vous n'avez pas traversé le processus douloureux d'essayer et d'échouer.
Vous essayerez une chose pour éviter une limite et en frapperez une autre dans un jeu sans fin de "détourner une limite". Dans le processus, vous devrez ré-architecturer radicalement l'ensemble de votre application et de votre approche, ainsi que réécrire tout votre code de test. Vous devez avoir une couverture de code de test de 75% à déployer en production, ce qui est en fait une très bonne chose, mais combiné avec toutes les autres limites, c'est très lourd. Vous atteindrez en fait les limites du gouverneur en écrivant votre code de test qui ne se présenterait pas dans les scénarios utilisateur normaux, mais cela vous empêcherait d'atteindre la couverture.
Sans parler de toute une série d'autres questions. L'emballage n'est pas ce que vous attendez. Vous ne pouvez pas empaqueter votre application et la livrer aux utilisateurs sans intervention et configuration importantes de la part de l'administrateur de l'organisation. L'AppExchange est une blague totale, et ils ont même commencé à charger 5K juste pour que votre application soit répertoriée. L'importation avec le chargeur de données est nul, surtout si vous avez des déclencheurs. Vous ne pouvez pas exporter toutes vos données en une seule étape qui inclut vos relations de telle manière qu'elles peuvent facilement être réimportées dans une autre organisation en une seule étape (par exemple une organisation de développement). Vous ne pouvez actualiser un bac à sable qu'une fois par mois depuis la production, sans exception, et vous ne pouvez pas inclure vos données dans une actualisation par défaut, sauf si vous avez appelé votre responsable de compte pour que cette fonctionnalité soit déverrouillée. Vous ne pouvez pas supprimer en masse des données dans des objets personnalisés. Vous ne pouvez pas modifier les noms de vos packages. Certaines choses peuvent prendre de nombreuses jours à terminer après que vous les ayez demandées, comme une sauvegarde des données avant de déployer une application, sans rapport de progression en cours de route et peu de sens du moment exact de l'exportation eu lieu. Étant donné qu'il existe des problèmes de synchronisation des données s'il existe des relations entre les données, il existe de graves problèmes d'intégrité des données en ce qu'il n'existe pas de "transaction" qui peut exporter de nombreux objets en une seule étape. Il existe probablement des outils commerciaux pour faciliter une partie de cela, mais ils ne sont pas à la portée des développeurs normaux qui peuvent ne pas avoir un budget énorme.
Tout le reste que les autres personnes ont dit ici est vrai. Il peut parfois prendre de cinq secondes à une minute pour enregistrer un fichier.
Je ne veux pas être si négatif parce que la plate-forme est très cool à certains égards et ils essaient de faire des choses dans un environnement multi-locataire que personne d'autre ne fait. C'est un environnement très innovant et puissant à certains niveaux (j'aime beaucoup VisualForce), mais donnez-lui encore un an ou deux. Ils s'associent avec VMware, peut-être que cela conduira à donner aux développeurs un peu plus un parc pour enfants plutôt qu'une cellule de prison dans laquelle travailler.
Voici quelques choses que je peux vous donner après avoir passé pas mal de temps à développer sur la plate-forme au cours des deux dernières semaines:
Il n'y a pas d'API RESTful. Ils ont une API basée sur du savon que vous pouvez appeler, mais il n'y a aucun moyen de faire de vrais appels reposants
Il n'y a pas de moyen simple de prendre leurs SObjects et de les convertir en objets JSON.
Les pages de force visuelle sont correctes jusqu'à ce que vous vouliez les personnaliser, puis c'est tout un monde de douleur.
Les pages de force visuelle doivent être liées aux SObjects, sinon il n'y a aucun moyen de faire fonctionner les champs de saisie standard comme le sélecteur de date ou la liste de sélection.
Le plugin Eclipse est ok si vous voulez travailler par vous-même, mais si vous voulez travailler dans une grande équipe avec le plugin Eclipse, oubliez-le. Il ne gère pas la synchronisation vers et depuis le serveur, il se bloque et ce n'est pas vraiment utile du tout.
LÀ IS PAS DE DÉBOGUEUR! Si vous voulez déboguer, il est littéralement débogué par les instructions system.debug. C'est probablement le plus gros problème que j'ai trouvé
Leur modèle "MVC" n'est pas vraiment MVC. C'est beaucoup plus proche des formulaires Web ASP.NET. Vos points de vue sont étroitement liés non seulement aux modèles mais également aux contrôleurs.
Le stockage d'un grand nombre de documents n'est pas possible. Nous devons stocker plus de 100 Go de documents et nous avons cité un chiffre ridicule. Nous avons décidé d'implémenter notre stockage de documents sur l'infrastructure Amazon S3
Même si le langage est Java basé, ce n'est pas Java. Vous ne pouvez pas importer de packages ou de bibliothèques externes. De plus, les bibliothèques de base disponibles sont sévèrement limitées, nous nous sommes donc retrouvés à implémenter un tas de choses en externe, puis exposer ces bits en tant que services qui sont appelés par force.com
Vous pouvez appeler des services externes SOAP ou REST), mais le corps du message est limité à 100 Ko, il est donc très restrictif de ce que vous pouvez appeler.
En toute honnêteté, bien qu'il y ait des avantages potentiels à développer sur quelque chose comme la plate-forme force.com, pour moi, vous ne pouvez pas utiliser la plate-forme force.com pour de vraies applications de niveau entreprise. Au mieux, vous pourriez écrire des applications basiques de style crud mais une fois que vous vous déplacerez vers quelque chose de compliqué à distance, je l'éviterais comme la peste.
Wow - il y a beaucoup de choses ici que je ne savais même pas quelles étaient les limites - après avoir travaillé sur la plate-forme pendant quelques années.
Mais juste pour ajouter d'autres choses ...
La raison pour laquelle vous n'avez pas de débogueur ligne par ligne est précisément parce que c'est une plate-forme multi-locataire. C'est du moins ce que dit SFDC - il semble qu'à l'ère de la programmation riche en threads, ce n'est pas vraiment une excuse, mais c'est apparemment la raison. Si vous devez écrire du code, vous avez "System.debug (String)" comme débogueur - je me souviens avoir eu des outils de débogage de serveur plus sophistiqués dans Java 1.2 il y a environ 12 ans).
Une autre chose que je déteste vraiment à propos du système est le contrôle de version. Le framework Spring n'est pas utilisé pour ce que Spring est généralement utilisé - il s'agit vraiment plus d'un outil de configuration dans SFDC que d'un contrôle de version. SFDC fournit un contrôle de version ZERO.
Vous pouvez vous retrouver coincé pendant des jours à faire quelque chose qui devrait sembler si ridiculement facile, comme, par exemple, planifier un rapport SFDC pour l'exporter vers un fichier CSV et envoyer un e-mail à une liste de destinataires ... Eh bien, la façon la plus simple de le faire est créer un objet personnalisé avec un champ personnalisé, avec une règle de workflow et un modèle d'e-mail Visualforce ... puis pour le code, vous devez écrire un composant Visualforce qui diffuse les données du rapport vers le modèle d'e-mail Visualforce en tant que pièce jointe et vous écrivez APEX anonyme mise à jour du champ de planification de code de l'objet personnalisé ... Pour les développeurs SFDC, c'est presque une tâche quotidienne ... essayer de rassembler environ cinq technologies différentes pour effectuer des tâches qui semblent si simples .... Et cela peut causer des maux de tête de gestion et les tensions aussi - En général, vous le découvririez après avoir reçu une suggestion de faire quelque chose qui ne fonctionne pas dans la communauté des utilisateurs (comme quelqu'un l'a déjà dit), puis en essayant beaucoup de choses qui, après les avoir développées, vous le feriez trouvent qu'ils ne fonctionnent tout simplement pas pour certains o raison dd-ball - comme "vous ne pouvez pas planifier une page VisualForce", ou "vous ne pouvez pas appeler getContent à partir d'un contexte planifiable" ou une autre raison mystérieuse.
Il y a tellement, beaucoup de petits accrochages exaspérants sur la plate-forme SFDC, qu'une fois que vous savez POURQUOI ils sont là, cela a du sens ... mais ce sont toujours de très mauvaises limitations qui vous empêchent de faire ce que vous devez faire. Voici certains des miens;
Vous ne pouvez pas obtenir les informations sur le propriétaire de l'enregistrement "hors de la boîte" sur à peu près n'importe quel type d'enregistrement - vous devez écrire un déclencheur qui lie le propriétaire lors de la création de l'enregistrement à l'enregistrement que vous insérez. Pourquoi? Réponse courte car un propriétaire peut être soit une "personne" ou une "file d'attente", et les deux sont des entités radicalement différentes ... C'est logique, mais cela peut bouleverser un projet littéralement.
Modèle de sécurité affolant. Exemple: l'autorisation "Gérer les rapports publics" est très différente de "Créer et personnaliser des rapports" et cela vaut pour tout sur la plate-forme ... en particulier les dossiers de toute nature.
Comme mentionné, le support est pratiquement inexistant. Si vous êtes une personne extrêmement autosuffisante, ou avez beaucoup de ressources SFDC, ou avez beaucoup de temps et/ou un gestionnaire très indulgent, ou êtes en charge d'un système SFDC qui fonctionne bien, vous êtes en assez bonne position forme. Si vous n'êtes dans aucune de ces positions, vous pouvez vous retrouver en grande difficulté.
SFDC est une proposition commerciale très séduisante ... aucune empreinte d'équipement, assez bonne sécurité, prix fixe, aucune infrastructure, ET vous obtenez un CRM basé sur le Web avec des traitements groupés et programmables ... Mais comme les autres affiches l'ont dit, c'est vraiment une montée en puissance de l'apprentissage du développement, et si vous optez pour le conseil, je pense que le prix le plus bas que j'ai vu était de 200 $/heure.
Salesforce a tendance à s'intégrer à d'autres choses des années après que certaines technologies soient devenues monnaie courante - JSON et jquery viennent à l'esprit ... et si vous avez d'autres infrastructures communes avec lesquelles vous souhaitez faire une intégration, comme JIRA, attendez-vous à payer beaucoup plus, et ils peuvent être assez bogués.
Et comme l'une des autres affiches mentionnées, vous combattez constamment les limites du gouverneur qui peuvent simplement vous rendre fou ... une pièce jointe ne peut PAS être> 5 Mo. Période. Et parfois <3 Mo (si encodé en base64). Dix légendes HTTP dans une classe. Période. Il existe des dizaines de limites de gouverneur publiées, et beaucoup ne sont pas celles que vous trouverez sans aucun doute et que vous voulez juste manquer de hurler.
J'aime vraiment, VRAIMENT la plateforme, mais croyez-moi - ça peut être une maîtresse vraiment cruelle.
Mais en toute justice pour SFDC, je dirais ceci: le plus gros problème que je trouve avec la plate-forme n'est pas la plate-forme elle-même, mais les attentes gargantuesques que presque tous ceux qui voient la plate-forme, mais ne l'ont pas développée, ont .... et ces personnes ont tendance à occuper des postes de grande autorité dans les organisations commerciales; marketing, ventes, gestion, etc. D'énormes déconnexions se produisent et les têtes roulent, ou sont menacées de rouler tous les jours - tout cela parce qu'il y a une excellente plate-forme avec des problèmes étranges et des milliers de personnes qui luttent quotidiennement pour comprendre pourquoi les choses devraient simplement fonctionner quand ils ne le font pas et ne le feront pas.
MODIFIER:
Juste pour ajouter aux commentaires de lomaxx sur le MVC; Dans la terminologie SFDC, cela est étroitement lié à ce que l'on appelle le "viewstate" - et il peut être vraiment bogué, en ce que ce qui est sur la page VF est pas ce qui est dans la classe contrôleur pour la page. Donc, vous devez traverser des girations étranges pour synchroniser ce qui est sur la page avec ce que le contrôleur va écrire sur SF lorsque vous cliquez sur votre bouton "enregistrer" (ou faites votre légende HTTP ou autre) .... mec, c'est ennuyeux .
Je pense que d'autres personnes ont couvert les inconvénients plus en profondeur, mais pour moi, il ne semble pas du tout utiliser le paradigme MVC ou soutenir beaucoup la réutilisation du code. Faire autre chose que de simples applications est un exercice de frustration par rapport au développement d'une application utilisant quelque chose comme ASP.Net MVC.
De plus, les outils, la couche de données et la frustration d'essayer de refactoriser le code ou de renommer des champs pendant le processus de développement n'aident pas.
Je pense qu'en tant que CMS, c'est plutôt cool, mais en tant que plate-forme pour des applications non CMS, cela n'a pas de sens pour moi.
Le modèle de sécurité est également très très restrictif ... mais ce n'est pas le pire. Vous ne pouvez pas actuellement affirmer si un utilisateur a la possibilité d'effectuer une action particulière.
Vous pouvez vérifier quel est leur rôle, mais vous ne pouvez pas vérifier si ce rôle dispose des autorisations pour effectuer l'action en cours.
Pire encore, la réponse du support technique est "essayez l'action et s'il y a une exception, rattrapez-la"
Étant donné que Force.com est une plate-forme "cloud", sa capacité à agir en tant que client d'un service externe défini par WSDL est assez décevante. Voir http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ pour ce que vous pourriez finir avoir à faire.
Je suppose qu'ils essaient de régler ces problèmes. À dreamforce, ils ont mentionné qu'ils essayaient de ramener les limites du gouverneur à seulement 4. Je ne sais pas quels sont les détails. Ils ont une API REST pour un accès anticipé, et ils ont acheté heroku qui est un développement Ruby dans le cloud. Ils ont divisé la base de données, avec database.com afin que vous puissiez effectuer tout votre développement Web et vos appels db en utilisant database.com.
Je suppose qu'ils essaient de le rendre aussi agnostique que possible. Mais pour le moment, ce sont toutes des annonces et un accès anticipé, de sorte que leurs déclarations Safe Harbor n'achètent pas sur ce qu'elles disent, seulement sur ce qu'elles ont actuellement.
Pour tout ce qui précède, je suis curieux de savoir comment la version de VMforce, permettant à Java d'écrire du code pour Force.com, change les inconvénients ci-dessus?
http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071