Inconvénients de la plate-forme Force.com

Question

Nous cherchons actuellement à notre plate-forme de développement à l’aide de la plate-forme Force.com et les gars de ventes et le site Web de force.com sont pleins de raisons pour lesquelles elle est la meilleure plate-forme dans le monde. Ce que je cherche, est cependant quelques inconvénients réels à l’utilisation d’une telle plate-forme.

Answer 1

Voici 10 pour obtenir vous avez commencé.

1. Apex est un langage propriétaire. Autre que le foce.com plug-in Eclipse, il y a peu ou pas de l'outillage disponible comme refactoring, analyse de code, etc.
2. L'Apex a été calqué sur Java 5, qui est considéré comme un être à la traîne derrière d'autres langues, et sans outils (voir #1), peut être assez lourd.
3. Le déploiement est encore assez manuel, avec beaucoup de pièges et d'étapes manuelles. Cette situation s'améliore lentement, au fil du temps, mais vous serez déçus si vous êtes habitué à avoir des déploiements automatisés.
4. Apex manque de paquets/espaces de noms. Toutes vos classes, interfaces, etc. vivre dans un dossier sur le serveur. Cela rend le code beaucoup moins organisé et de la classe/interface noms nécessairement long pour éviter les collisions de noms et de fournir un contexte. C'est l'une de mes plus grandes plaintes, et je ne voudrais pas librement choisir de construire sur force.com pour cette seule raison.
5. "Force.com IDE", aka force.com plug-in eclipse, est incroyablement lent. Enregistrer les fichiers, que ce soit un fichier de classe, fichier texte, etc., prend habituellement au moins 5 secondes et parfois jusqu'à 30 secondes en fonction du nombre d'objets, types de données, les fichiers de classe, etc. sont dans votre org. L'épargne est également une action de blocage, qui exige non seulement une compilation, mais une synchronisation complète de votre projet local avec le serveur. Les ordres de grandeur inférieure à celle de Java ou .NET.
6. La communauté de développeurs en ligne ne semble pas en très bonne santé. J'ai remarqué que beaucoup de posts sur le forum sans réponse ou non résolus. Je pense que cela peut avoir quelque chose à voir avec le forum logiciel salesforce.com utilise, ce qui semble pour le sucer assez dur.
7. Les données d'accès DSL à Apex laisse beaucoup à désirer. Il n'est pas même à distance, en concurrence avec les goûts de (N)Hibernate, JPA, etc.
8. Le développement d'une application sur l'Apex/VisualForce est un exercice de gouverneur limites de l'ingénierie. Facilement la moitié de programmeur temps passé à tenter de l'optimiser pour éviter les nombreux gouverneur de limites et d'autres pièges comme visualforce de l'état d'affichage des limites. Il pourrait être soutenu que si vous écrivez un code efficace pour commencer, vous n'aurez pas ce problème, ce qui est vrai dans une certaine mesure. Cependant, il ya beaucoup de fois que vous avez des raisons valables de le faire de plus de x requêtes dans une session, ou en boucle au travers de plus de x enregistrements, etc.
9. Le save->compiler->exécuter cycle est extrêmement lente, esp. quand il s'agit de la compression et de télécharger l'ensemble de la ressource statique bundle juste pour faire quelque chose comme le test d'un mineur de css ou de javascript changement.
10. En général, la douleur d'un jeune, plate-forme naissante, sans les avantages de l'open source. Vous n'avez aucun moyen de valider et/ou corriger des bugs dans la plate-forme. Ils disent de le poster à leur IdeaExchange. Ouais, bonne chance avec ça.

Responsabilité/Communications: Il y a beaucoup d'avantages à une plate-forme d'hébergement tels que force.com. Force.com le fait régulièrement améliorer la plate-forme. Il y a beaucoup de choses à son sujet, que j'aime. - Je faire de l'argent sur la construction force.com

Answer 2

Je vois que vous avez obtenu de réponses à certaines questions, mais je tiens à rappeler combien de temps est perdu à faire le tour de l'différents gouverneur de limites sur la plate-forme. Autant que j'aime la plate-forme sur certains niveaux, je vous serais très fortement, très fortement, avec insistance recommande contre elle, comme un général de la plateforme de développement d'application. Il est grand comme un super configurable et extensible CRM d'application, si c'est ce que vous voulez. Alors que leur marketing est exceptionnel à pousser l'idée de Force.com général de la plate-forme de développement, il n'est même pas de près ou de loin encore.

L'efficacité de disposer d'une plate-forme stable et éviter les grandes performances et des problèmes de stabilité est facilement gaspillé à essayer de contourner les limites que les gens se réfèrent. Il existe de nombreuses limites à la plate-forme, il devient complètement fou. Ces limites ne sont pas haut de gamme des limites, vous serez frappé une fois que vous avez beaucoup d'utilisateurs, vous serez frappé presque tout de suite.

Bien qu'il existe généralement des techniques pour obtenir autour d'eux, il est très difficile de déterminer des stratégies pour les éviter pendant que vous êtes aussi en train d'essayer de développer la logique métier de votre application.

Pour vous donner une idée de comment le développeur de l'onu respectueux de l'environnement est, prendre le "manque de débogage de l'environnement" visées ci-dessus. C'est pire que ça. Vous ne pouvez en voir un maximum de 20 les plus récents de demandes vers le serveur dans les journaux de débogage. Donc, comme vous êtes en développement à l'intérieur de l'application, vous devez créer une "Nouvelle" demande de débogage, sélectionnez votre nom, appuyez sur "Enregistrer", revenir à votre application, actualisez la page, cliquez sur retour à votre onglet débogage, essayez de trouver la demande, qui abritera votre journal de débogage, cliquez sur "rechercher" pour rechercher le texte que vous recherchez. C'est comme dix clics pour regarder une sortie de débogage. Même si cela peut sembler banal, mais c'est juste un exemple de la façon dont peu d'attention et de considération a été donné par le développeur de l'expérience.

Tout sur la plate-forme de développement est un greffé sur coup. Il est remarquable pour ce qu'il est, mais un total de PITA pour la plupart. Si vous ne savez pas exactement ce que vous faites (comme vous êtes certifiés et ont une très bonne compréhension de l'Apex), il sera facilement vous prendre plus de 10-20x la quantité de temps qu'il serait dans un autre environnement, à faire quelque chose qui semble comme il serait ridiculement simple, si vous pouvez même réussir à tous.

Le gouverneur limites sont, en effet, que de mauvais. Vous avez une combinaison de plusieurs limites (requêtes de base de données, les lignes renvoyées, "instructions de script", les futurs appels, les légendes, etc.) et vous devez savoir exactement ce que vous faites pour les éviter. Par exemple, si vous avez un calcul cumulatif "formule" champ sur un objet et que vous avez un trigger sur un objet enfant, il va exécuter l'objet parent les déclencheurs et de compter ceux qui sont contre vos limites. Des choses comme ça ne sont pas évidents jusqu'à ce que vous avez passé par le processus douloureux d'essayer et d'échouer.

Vous allez essayer une chose à éviter une limite, et de frapper de l'autre dans un jeu interminable de "whack une limite". Dans le processus, vous aurez considérablement la re-architecte de l'ensemble de votre application et de l'approche, ainsi que de réécrire tout votre code de test. Vous devez avoir 75% de couverture de code de tests de déployer en production, qui est en fait une très bonne chose, mais combiné avec tous les autres limites, il est très lourde. Vous aurez effectivement frappé le gouverneur limites de l'écriture de votre code de test qui ne viennent pas en utilisateur normal scénarios, mais qui va vous empêcher d'atteindre la couverture.

C'est pour ne pas mentionner une foule d'autres questions. L'emballage n'est pas ce que vous attendez. Vous ne pouvez pas le package de votre application et de le livrer aux utilisateurs, sans intervention de l'utilisateur et de la configuration de la part de l'administrateur de l'organisation. La plate-forme AppExchange est une bêtise totale, et ils ont même commencé à charge 5K juste pour obtenir votre application répertoriée. L'importation avec le chargeur de données suce, surtout si vous avez des déclencheurs. Vous ne pouvez pas exporter toutes vos données en une seule étape, qui comprend vos relations de telle sorte qu'il peut facilement être importé dans un autre org en une seule étape (par exemple un dev org). Vous ne pouvez actualiser un bac à sable une fois par mois à partir de la production, sans exceptions, et vous ne pouvez pas inclure vos données dans une actualisation par défaut, sauf si vous avez appelé votre directeur de compte pour obtenir cette fonctionnalité déverrouillé. Vous ne pouvez pas masse de supprimer des données dans des objets personnalisés. Vous ne pouvez pas changer les noms de paquets. Certaines choses peuvent prendre plusieurs jours pour terminer après que vous avez demandés, comme une sauvegarde des données avant de vous souhaitez déployer une application, aucun rapport d'avancement le long de la manière, et pas beaucoup de sens quand exactement l'exportation. Étant donné qu'il y a une synchronicité problèmes de données si il y a des relations entre les données, il y a de graves problèmes d'intégrité des données, il n'existe pas une telle chose comme une "opération" qui peuvent exporter de nombreux objets en une seule étape. Il ya probablement des outils commerciaux pour faciliter une partie de cela, mais ils ne sont pas à la portée normale des développeurs qui n'ont pas un énorme budget.

Tout le reste, les autres ont dit ici est vrai. Il peut prendre n'importe où de cinq secondes à une minute, parfois, d'enregistrer un fichier.

Je ne veux pas être si négatif, car la plate-forme est très cool, à certains égards, et qu'ils essayent de faire les choses dans un multi-locataire de l'environnement que personne d'autre est en train de faire. C'est un environnement innovant et puissant sur certains niveaux (en fait, j'aime VisualForce beaucoup), mais de lui donner une autre année ou deux. Ils sont en partenariat avec VMware, peut-être, qui conduisent à donner aux développeurs un peu plus d'un parc plutôt que d'une cellule de prison.

Answer 3

Voici quelques choses que je peux vous donner, après avoir passé un peu juste de temps à développer sur la plate-forme dans la dernière quinzaine:

1. Il n'y a pas d'API RESTful. Ils ont un savon à base d'api, vous pouvez l'appeler, mais il n'y a aucun moyen de le faire vrai appels restful

2. Il n'y a pas de moyen simple de prendre leur Nessobjects et de les convertir en objets JSON.

3. La force visuelle des pages sont ok jusqu'à ce que vous souhaitez personnaliser et puis c'est tout un monde de douleur.

4. Force visuelle des pages doivent être liés à Nessobjects autrement il n'y a aucun moyen d'obtenir de l'entrée standard des domaines comme le datepicker ou sélectionner la liste de travail.

5. Le plugin eclipse est ok si vous voulez travailler par vous-même, mais si vous souhaitez travailler dans une grande équipe avec le plugin eclipse de l'oublier. Il ne supporte pas la synchronisation avec le serveur, il se bloque et il n'est pas vraiment utile à tous.

6. IL N'Y A PAS DE DÉBOGUEUR! Si vous souhaitez déboguer, il est littéralement debug par le système.des instructions de débogage. C'est probablement le plus gros problème que j'ai trouvé

7. Leur "MVC" modèle n'est pas vraiment MVC. C'est beaucoup plus proche de ASP.NET Webforms. Vos points de vue sont étroitement couplées non seulement les modèles, mais les contrôleurs.

8. Stocker une grande quantité de documents n'est pas possible. Nous avons besoin de stocker plus de 100 go de documents et nous avons cité quelques chiffre ridicule. Nous avons décidé de mettre en œuvre notre système de stockage de documents sur les amazones S3 infrastructure

9. Même quand la langue est basé sur java, ce n'est pas java. Vous ne pouvez pas importer de paquets externes ou des bibliothèques. Aussi les librairies de base qui sont disponibles sont très limitées, de sorte que nous avons trouvé nous-mêmes la mise en œuvre d'un tas de choses de l'extérieur et en l'exposant ensuite ces morceaux comme des services qui sont appelés par force.com

10. Vous pouvez appeler à l'externe SOAP ou REST services, mais le corps du message est limitée à 100 ko, ce qui est très restrictif en ce que vous pouvez appeler.

En toute honnêteté, alors qu'il existe des avantages potentiels de développement sur quelque chose comme les force.com plate-forme, pour moi, vous ne pouvez pas utiliser la force.com plate-forme pour le vrai niveau de l'entreprise applications. Au mieux, vous pourriez écrire quelques crud de base des applications de style, mais une fois que vous vous déplacez dans quelque chose à distance compliqué, je serais l'éviter comme la peste.

Answer 4

Wow - il y a beaucoup de choses ici que je ne savais même pas eu des limites - après avoir travaillé sur la plate-forme pour quelques années.

Mais juste pour ajouter quelques autres choses...

La raison pour laquelle vous n'avez pas une ligne-par-ligne débogueur est précisément parce qu'elle est une plate-forme partagée. Au moins, c'est ce SFDC, dit - il semble que, dans cet âge de fil-une programmation riche, ce n'est pas une excuse, mais c'est apparemment la raison. Si vous devez écrire du code, vous avez "le Système de.debug(String)" que votre débogueur - je me souviens d'avoir plus sophistiqués server outils de débogage en Java 1.2 il y a 12 ans.

Une autre chose que je déteste vraiment sur le système de contrôle de version. Le framework Spring est pas utilisé pour ce Printemps est généralement utilisé pour l' - c'est vraiment plus un outil de configuration en SFDC plutôt que de contrôle de version. SFDC fournit ZÉRO de contrôle de version.

Vous pouvez vous retrouver coincé pendant des jours, en faisant quelque chose qui semble si ridiculement facile, comme, par exemple, de la planification d'un SFDC rapport à exporter vers un fichier CSV et l'e-mail à une liste de destinataires... eh Bien, la façon la plus simple de le faire est de créer un objet personnalisé avec un champ personnalisé, avec une règle de workflow et un Visualforce modèle d'e-mail... et puis pour le code, vous devez écrire un Visualforce composant de flux de données du rapport de la Visualforce modèle d'e-mail en tant que pièce jointe et vous écrivez anonyme APEX code annexe de champ-mise à jour de l'objet personnalisé... Pour SFDC les développeurs, c'est presque une tâche quotidienne... en essayant de le mettre sur cinq technologies différentes pour faire les tâches que l'air si simple.... Et cela peut provoquer la gestion des maux de tête et des tensions trop Généralement, vous trouverez ce après l'obtention d'une suggestion à faire quelque chose qui ne fonctionne pas dans la communauté des utilisateurs (comme quelqu'un l'a déjà dit), et puis d'essayer beaucoup de choses qui, après avoir développé leur, que vous pouvez trouver, elles ne fonctionnent pas pour certains odd-ball raison - comme "vous ne pouvez pas planifier une page VisualForce", ou "vous ne pouvez pas appeler getContent à partir d'une préférence d'heure de contexte", ou quelque autre des arcanes de la raison.

Il y a donc beaucoup, beaucoup de affolant peu gotcha sur le SFDC plate-forme, qu'une fois que vous savez POURQUOI ils sont là, il tombe sous le sens... mais ils sont toujours très mauvais limitations qui vous empêchent de faire ce que vous devez faire. Voici quelques-unes des miennes;

1. Vous ne pouvez pas obtenir détenteur du record de l'information "out of the box" sur à peu près n'importe quel genre de tenue que vous avez à écrire un déclencheur qui lie le propriétaire à créer de l'enregistrement pour l'enregistrement de l'insertion. Pourquoi? Réponse courte car un propriétaire peut être soit une "personne" ou une "file d'attente", et les deux sont radicalement différentes entités... du bon sens, mais il peut transformer un projet littéralement à l'envers.

2. Affolant modèle de sécurité. Exemple: "Gérer les Rapports de" l'autorisation est très différent de "Créer et de Personnaliser les Rapports" et qui, en gros, vaut pour tout, sur la plate-forme... en particulier les dossiers de toute nature.

3. Comme mentionné, le soutien est essentiellement inexistant. Si vous êtes un très auto-suffisante individu, ou ont beaucoup de SFDC ressources, ou avoir beaucoup de temps et/ou un très indulgent manager, ou sont en charge d'un SFDC système qui fonctionne bien, vous êtes en assez bonne forme. Si vous n'êtes pas dans l'un de ces postes, vous pouvez trouver vous-même dans le pétrin.

SFDC est un très séduisante proposition d'affaires... aucun équipement d'empreinte, une assez bonne sécurité, à prix fixe, pas d'infrastructure, ET vous obtenez CRM basé sur le web avec batchable, et schedualble de traitement... Mais comme les autres posters dit, c'est vraiment un ramp-up dans le développement de l'apprentissage, et si vous allez à la consultation, je pense que le prix le plus bas que j'ai vu était de 200 $l'heure.

Salesforce a tendance à intégrer avec d'autres choses que des années après certaines technologies devenu commun-place - JSON et jquery viennent à l'esprit... et si vous avez d'autres infrastructures communes que vous voulez faire une intégration avec, comme JIRA, s'attendre à payer beaucoup plus, et ils peuvent être assez buggé.

Et comme l'un de l'autre, des affiches mentionnées, vous êtes constamment lutter contre le gouverneur de limites que peut seulement vous conduire noix... une pièce jointe ne peut PAS être > 5 MO. Période. Et parfois < 3 MO (si encodées en base64). Dix HTTP légendes dans une classe. Période. Il y a des dizaines d'publié le gouverneur de limites, et beaucoup de ceux qui ne sont pas qui vous trouverez sans aucun doute et vous voulez juste pour s'exécuter hors de votre bureau en hurlant.

J'ai vraiment, vraiment comme la plate-forme, mais croyez-moi -, il peut être vraiment la maîtresse cruelle.

Mais en toute équité, à 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 le gargantuesque attentes que presque tout le monde qui voit la plate-forme, mais n'a pas élaboré sur la il a.... et ces gens ont tendance à être dans des positions d'autorité dans les organisations d'entreprises, marketing, vente, gestion, etc. Énorme déconnecte se produire et les chefs rouleau, ou sont menacés de rouler quotidien - tout cela parce qu'il y a cette grande plate-forme là-bas avec bizarre pièges et des milliers de personnes qui luttent au quotidien pour comprendre pourquoi les choses devrait fonctionner quand ils ne sont pas et ne le seront pas.

EDIT:
Juste pour ajouter à lomaxx commentaires sur le MVC; Dans SFDC terminologie, cela est étroitement lié à ce qui est connu comme "l'état d'affichage" -- et il peut être vraiment buggy, que ce qui est sur la VF de la page est pas ce qui est dans le contrôleur de classe pour la page. Donc, vous devez aller à travers bizarre fluctuations de synchroniser ce qui se passe sur la page avec ce que le contrôleur va écrire de la SF quand vous cliquez sur le bouton "enregistrer" (ou de faire votre HTTP légende ou quoi que ce soit).... l'homme, c'est ennuyeux.

Answer 5

Je pense que d'autres personnes ont couvert les inconvénients plus en profondeur, mais pour moi, il n'a pas l'air d'utiliser le paradigme MVC ou de soutien beaucoup dans la façon de réutiliser le code. Rien à faire, au-delà de simples applications est un exercice de frustration par rapport au développement d'une application en utilisant quelque chose comme ASP.Net MVC.

En outre, les outils, les données et la couche de la frustration d'essayer de refactorisation de code ou de renommer des champs pendant le processus de développement n'aide pas.

Je pense que comme un CMS, c'est assez cool, mais comme une plate-forme pour les non applications CMS, il ne fait pas de sens pour moi.