Question

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

Était-ce utile?

La solution

Voici 10 pour démarrer.

  1. Apex est un langage propriétaire. Autre que le plug-in Eclipse force.com, il y a peu ou pas d'outillage disponible tels que refactoring, analyse de code, etc.
  2. Apex a été calqué sur Java 5, qui est considéré comme en retard d'autres langues, et sans outillage (voir # 1), peut être assez lourd.
  3. Le déploiement est encore manuel assez avec beaucoup de gotchas et étapes manuelles. Cette situation s'améliore lentement au fil du temps, mais vous serez déçu si vous êtes habitué à avoir des déploiements automatisés.
  4. Apex manque paquets / namespaces. Toutes vos classes, interfaces, etc. vivent dans un dossier sur le serveur. Cela rend beaucoup moins de code organisé et noms de classe / interface nécessairement long pour éviter les conflits de noms et de fournir un contexte. C'est l'une de mes plus grandes plaintes, et je ne choisirait pas librement de construire sur force.com pour cette seule raison.
  5. Le "force.com IDE", alias force.com plugin Eclipse, est incroyablement lent. Enregistrement tout fichier, 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 aussi une action de blocage, ce qui nécessite la compilation non seulement, mais une synchronisation complète de votre projet local avec le serveur. Ordres de grandeur plus lent que Java ou .NET.
  6. La communauté des développeurs en ligne ne semble pas très sain. Je l'ai remarqué beaucoup de messages du forum restent sans réponse ou sans solution. Je pense que cela peut avoir quelque chose à voir avec le logiciel de forum salesforce.com utilise, ce qui semble sucer assez dur.
  7. Le DSL d'accès aux données à Apex laisse beaucoup à désirer. Il est même pas à distance concurrentiel avec les goûts de (N) Hibernate, JPA, etc.
  8. Développer une application sur Apex / Visualforce est un exercice gouverneur ingénierie des limites. Facilement la moitié du temps de programmation fut consacré à essayer d'optimiser pour éviter les nombreuses limites de gouverneur et d'autres gotchas comme les limites de l'état de vue 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 beaucoup de fois que vous avez des raisons valables pour faire plus de requêtes x dans une session, ou d'une boucle à travers plus de dossiers x, etc.
  9. Le Enregistrer-> compile-> du cycle d'exécution est extrêmement lent, esp. quand il implique la compression et le téléchargement du paquet entier de ressource statique juste pour faire quelque chose comme un test de CSS mineur ou javascript changement.
  10. En général, la douleur d'une jeune plate-forme naissante sans les avantages de celui-ci étant open source. Vous avez aucun moyen de valider et / ou corriger des bugs dans la plate-forme. Ils disent poster à leur IdeaExchange. Ouais, bonne chance avec ça.

Avertissements / Informations à fournir: Il y a beaucoup d'avantages à une plate-forme hébergée tels que force.com. Force.com n'améliore régulièrement la plate-forme. Il y a beaucoup de choses à ce sujet que j'aime. Je fais de l'argent sur la construction force.com

Autres conseils

Je vous ai obtenu quelques réponses, voir mais je voudrais réitérer combien de temps est gaspillé contourner les différentes limites de gouverneur sur la plate-forme. Autant que j'aime la plate-forme sur certains niveaux, je très fortement, très, recommande avec insistance contre elle, comme une plate-forme de développement d'application générale. Il est grand comme une application CRM super configurable et extensible si c'est ce que vous voulez. Alors que leur commercialisation est exceptionnel à pousser l'idée de Force.com en tant que plate-forme de développement général, ce n'est pas même de loin encore.

L'efficacité d'avoir une plate-forme stable et d'éviter de gros problèmes de performance et de stabilité est facilement gaspillés en essayant de coder autour des limites que les gens se réfèrent. Il y a tellement de limites à la plate-forme, il devient tout à fait exaspérant. Ces limites ne sont pas des limites haut de gamme, vous aurez touché une fois que vous avez beaucoup d'utilisateurs, vous les frapper presque tout de suite.

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 alors que vous êtes aussi essayer de développer la logique métier de votre application effective.

Pour vous donner une idée simple comment un développeur convivial l'environnement, prendre le « manque d'environnement de débogage » mentionné ci-dessus. Il est pire que cela. Vous ne pouvez voir jusqu'à 20 des demandes les plus récentes du serveur dans les journaux de débogage. Donc, comme vous développez dans l'application, vous devez créer une requête de débogage « Nouveau », sélectionnez votre nom, cliquez sur « Enregistrer », revenez à votre application, actualiser la page, cliquez à votre onglet de débogage, essayez de trouver la demande qui hébergera votre journal de débogage, appuyez sur « trouver » pour rechercher le texte que vous recherchez. Il est comme dix clics pour regarder une sortie de débogage. Bien qu'il puisse sembler trivial, il est juste un exemple de la façon dont peu de soin et attention a été accordée à l'expérience du développeur.

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

Les limites de gouverneur sont en effet mal que ça. Vous avez une combinaison de différentes limites (requêtes de base de données, lignes renvoyées, « instructions de script », les futurs appels, légendes, etc.) et vous devez savoir exactement ce que vous faites pour les éviter. Par exemple, si vous avez un champ « formule » rollup calculée sur un objet et vous avez un déclencheur sur un objet enfant, il exécutera les objets déclencheurs parents et compter ceux qui sont contre vos limites. Des choses comme ça ne sont pas évidents jusqu'à ce que vous avez passé à travers le processus douloureux d'essayer et de ne pas.

Vous allez essayer une chose pour éviter une limite, et frapper un autre dans un jeu sans fin de « Whack une limite ». Dans le processus, vous devrez re-architecte de façon drastique l'ensemble de votre application et de l'approche, ainsi que réécrire tout le code de test. Vous doit ont une couverture de code de test de 75% à se déployer dans la production, qui est en fait très bonne chose, mais combiné avec toutes les autres limites, il est très lourd. Vous aurez en fait frappé les limites de gouverneur l'écriture de votre code de test qui ne serait pas venir dans les scénarios d'utilisation normale, mais qui vous empêchera d'atteindre la couverture.

Cela ne veut pas parler d'une foule d'autres questions. L'emballage est pas ce que vous attendez. Vous ne pouvez pas emballer votre application et de le livrer aux utilisateurs sans intervention de l'utilisateur significatif et la configuration de la part de l'administrateur de l'org. AppExchange est une blague totale, et ils ont même commencé à faire payer 5 km juste pour obtenir votre application répertoriée. 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 quicomprend vos relations de telle sorte qu'il peut facilement être réimporté dans une autre org en une seule étape (par exemple une org dev). Vous ne pouvez actualiser un bac à sable une fois par mois de la production, sans exception, et vous ne pouvez pas inclure vos données dans un rafraîchissement par défaut, à moins que vous avez appelé votre responsable de compte pour obtenir cette fonctionnalité débloquée. Vous ne pouvez pas supprimer les données de masse dans des objets personnalisés. Vous ne pouvez pas modifier vos noms de paquets. Certaines choses peuvent prendre de nombreuses jours pour terminer après les avoir demandé, comme une sauvegarde de données avant que vous souhaitez déployer une application, sans rapport d'étape le long du chemin et pas beaucoup de sens quand exactement l'exportation eu lieu. Étant donné qu'il ya des problèmes de synchronicité de données s'il existe des relations entre les données, il y a de graves problèmes d'intégrité des données qu'il n'y a pas une telle chose comme une « transaction » qui peut exporter de nombreux objets en une seule étape. Il y a probablement des outils commerciaux pour faciliter certains de cela, mais ceux-ci ne sont pas à portée de main pour les développeurs normaux qui ne peuvent pas avoir un énorme budget.

Tout le reste les autres personnes ont dit ici est vrai. Il peut prendre de cinq secondes à une minute parfois d'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 ne fait d'autre. Il est un environnement très puissant et innovant sur certains niveaux (j'aime vraiment beaucoup Visualforce), mais lui donne une autre année ou deux. Ils sont en partenariat avec VMware, peut-être qui conduira à donner aux développeurs un peu plus d'un parc plutôt qu'une cellule de prison pour travailler.

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 de jours:

  1. Il n'y a pas API RESTful. Ils ont une API à base de savon que vous pouvez appeler, mais il n'y a aucun moyen de faire de vrais appels reposant

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

  3. Les pages de force visuelle sont ok jusqu'à ce que vous voulez les personnaliser et il est un monde de douleur.

  4. pages force visuelle doivent être liés à SObjects sinon il n'y a pas moyen d'obtenir les champs d'entrée standard comme la datepicker ou d'une liste de sélection pour travailler.

  5. 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 oublier. Il ne gère pas la synchronisation et à partir du serveur, il se bloque et il est pas vraiment utile du tout.

  6. IL Y A Debugger! Si vous voulez déboguer, il est littéralement débogué par des déclarations de system.debug. Ceci est probablement le plus gros problème que j'ai trouvé

  7. Leur modèle "MVC" n'est pas vraiment MVC. Il est beaucoup plus proche de ASP.NET WebForms. Vos points de vue sont étroitement couplés à non seulement les modèles mais les contrôleurs aussi bien.

  8. Enregistrement d'un grand nombre de documents est impossible. Nous avons besoin de stocker plus de 100 Go de documents et de nous ont donné une figure ridicule. Nous avons décidé de mettre en œuvre notre stockage de documents sur l'infrastructure S3 amazons

  9. Quand bien même la langue est basée sur Java, ce n'est pas java. Vous ne pouvez pas importer des packages externes ou bibliothèques. En outre, les bibliothèques de base qui sont disponibles sont très limitées pour que nous nous avons trouvé la mise en œuvre d'un tas de choses à l'extérieur, puis d'exposer ces bits comme les services qui sont appelés par force.com

  10. Vous pouvez appeler SOAP externe ou REST base mais le corps du message est limité à des années 100kb il est donc très restrictive dans ce que vous pouvez appeler.

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

Ouah, il y a beaucoup de choses ici que je ne savais même étaient des 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 ne disposez pas d'un débogueur ligne par ligne est précisément parce qu'elle est une plate-forme multi-locataire. Au moins ce que dit SFDC - il semble que dans cette ère de programmation de fil riche, ce n'est pas beaucoup d'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 d'avoir des outils de débogage de serveur plus sophistiqués en Java 1.2 il y a environ 12 ans

Une autre chose que je déteste vraiment le système est le contrôle de version. Le cadre de printemps n'est pas utilisé pour ce printemps est habituellement utilisé pour - il est vraiment plus large d'un outil de configuration dans SFDC plutôt que le contrôle de version. SFDC fournit ZERO version contrôle.

Vous pouvez vous retrouver coincé pendant des jours à faire quelque chose qui devrait sembler ridiculement facile, comme, par exemple, la planification d'un rapport SFDC d'exporter vers un fichier CSV et le courrier électronique à une liste de destinataires ... Eh bien, au sujet de la meilleure façon faire cela est de créer un objet personnalisé avec un champ personnalisé, avec une règle de workflow et un modèle de courrier électronique Visualforce ... et pour le code dont vous avez besoin d'écrire un composant Visualforce qui diffuse les données du rapport au modèle de courrier électronique Visualforce comme une pièce jointe et vous écrire champ de mise à jour de calendrier de code APEX anonyme de l'objet personnalisé ... pour les développeurs SFDC, ce qui est presque une tâche quotidienne ... essayant de mettre environ cinq technologies différentes ensemble pour faire des tâches qui semblent si simples .... Et cela peut causer des maux de tête et de gestion des tensions trop - en règle générale, vous pouvez trouver ceci après avoir obtenu une suggestion de faire quelque chose qui ne fonctionne pas dans l'utilisateur communautaire (comme quelqu'un l'a déjà dit), puis essayer beaucoup de choses qui, après les développés vous trouveriez qu'ils ne fonctionnent pas si moi-ball raison étrange -. comme « vous ne pouvez pas planifier une page Visualforce », ou « vous ne pouvez pas appeler getContent d'un contexte planifiable » ou une autre raison Arcane

Il y a tellement beaucoup, beaucoup de petites années Gotcha affolantes sur la plate-forme SFDC, qu'une fois que vous savez pourquoi ils sont là, il est logique ... mais ils sont encore des limites très mauvaises qui vous empêchent de faire ce que vous devez faire. Voici quelques-unes de mes;

  1. Vous ne pouvez pas obtenir des informations propriétaire enregistrement « de la boîte » sur à peu près tout type d'enregistrement - vous devez écrire un déclencheur qui lie le propriétaire à créer de l'enregistrement à l'enregistrement que vous insérez . Pourquoi? Réponse courte parce qu'un propriétaire peut être une « personne » ou une « file d'attente », et les deux entités sont radicalement différentes ... est logique, mais il peut transformer un projet littéralement à l'envers.

  2. modèle de sécurité exaspérant. Exemple:. L'autorisation « Gérer les rapports publics » est très différent de « Créer et personnaliser les rapports » et qui va essentiellement pour tout sur la plate-forme ... en particulier les dossiers de toute nature

  3. Comme mentionné précédemment, le soutien est pratiquement inexistante. Si vous êtes extrêmement autonome individuel, ou qui ont beaucoup de ressources SFDC, ou qui ont beaucoup de temps et / ou d'un gestionnaire très indulgent, ou sont en charge d'un système SFDC qui fonctionne bien, vous êtes assez bon forme. Si vous n'êtes pas dans l'une de ces positions, vous pouvez vous retrouver en grande difficulté.

SFDC est une proposition commerciale très séduisante ... pas empreinte d'équipement, assez bonne sécurité, prix fixe, pas d'infrastructure, et vous obtenez CRM Web avec batchable et le traitement schedualble ... Mais comme les autres affiches dit, il est vraiment tout à fait une montée en puissance de l'apprentissage du développement, et si vous allez avec le conseil, je pense que le prix le plus bas que je l'ai vu était de 200 $ / heure.

Salesforce a tendance à intégrer d'autres choses années après certaines technologies deviennent des lieux communs - JSON et jquery viennent à l'esprit ... et si vous avez d'autres infrastructures communes que vous voulez faire une intégration avec, comme JIRA, attendez-vous à payerbeaucoup plus, et ils peuvent être tout à fait buggy.

Et comme l'une des autres affiches mentionnées, vous combattez sans cesse les limites de gouverneur qui peut juste vous conduire noix ... une pièce jointe ne peut pas être> 5MB. Période. Et parfois <3 Mo (si codé en base64). Dix HTTP dans les légendes d'une classe. Période. Il y a des dizaines de limites de gouverneur publiées, et beaucoup qui ne sont pas que vous trouverez sans aucun doute et que vous voulez juste courir de votre bureau en hurlant.

Je vraiment, vraiment comme la plate-forme, mais croyez-moi - il peut être une maîtresse vraiment cruelle.

Mais en toute justice pour SFDC, je dirais ceci: le plus gros problème que je trouve la plate-forme n'est pas la plate-forme elle-même, mais les attentes gargantuesques que presque tout le monde qui voit la plate-forme, mais n'a pas développé sur elle a. ... et les gens ont tendance à être en position d'une grande autorité dans les organisations professionnelles; marketing, ventes, gestion, etc. déconnexions énormes se produisent et les têtes roulent, ou sont menacés de rouler tous les jours - parce qu'il ya cette grande plate-forme là-bas avec gotchas étranges et des milliers de personnes qui luttent chaque jour pour obtenir la tête autour de pourquoi les choses devraient simplement travailler quand ils ne pas et ne sera pas.

EDIT:
Il suffit d'ajouter aux commentaires de lomaxx sur le MVC; Dans la terminologie SFDC, cela est étroitement lié à ce qui est connu sous le nom « VIEWSTATE » - AAND il peut être vraiment bogué, dans ce qui est sur la page VF est pas ce qui est dans le contrôleur de classe pour la page. Donc, vous devez aller throught girations étranges pour ce qui est synch sur la page avec ce que le contrôleur va écrire à SF lorsque vous cliquez sur le bouton « Enregistrer » (ou faire votre HTTP ou callout autre) .... l'homme, il est ennuyeux .

Je pense que d'autres personnes ont couvert les inconvénients plus en profondeur mais pour moi, il ne semble pas utiliser le paradigme MVC ou soutenir beaucoup de la manière de la réutilisation de code du tout. Pour ce faire quoi que ce soit au-delà des applications simples est un exercice de frustration par rapport au développement d'une application à l'aide quelque chose comme ASP.Net MVC.

En outre, les outils, la couche de données et la frustration d'essayer de factoriser le code ou renommer des champs au cours du processus de développement ne contribue pas.

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

Le modèle de sécurité est aussi très très restrictive ... mais ce n'est pas le pire. Vous ne pouvez pas affirmer actuellement si un utilisateur a la possibilité d'effectuer une action particulière.

Vous pouvez vérifier ce que leur rôle est, mais vous ne pouvez pas vérifier si ce rôle est autorisé à effectuer l'action en cours.

Pire encore est la réponse du support technique « d'essayer l'action et s'il y a une exception, l'attraper »

Considérant Force.com est une plate-forme « nuage », sa capacité à agir en tant que client à un service défini WSDL-externe 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 par avoir à faire

GROUPÉ, je suis curieux de voir comment la libération de VMforce, ce qui permet programmeur Java d'écrire du code pour Force.com, modifie les inconvénients ci-dessus?

http://www.zdnet.com/ blog / saas / vmforcecom-redéfinit-the-ZAP-paysage / 1071

Je suppose qu'ils tentent de résoudre ces problèmes. A Dreamforce ils ont mentionné qu'ils nous essayons de laisser tomber les limites du gouverneur à seulement 4. Je ne suis pas sûr de ce que les détails sont. Ils ont une API REST pour l'accès précoce, et ils ont acheté Heroku qui est un développement rubis dans le nuage. Ils se séparent sur la base de données, avec database.com afin que vous puissiez faire tout votre développement web et sur votre db appels à l'aide database.com.

Je suppose qu'ils essaient de le rendre aussi agnostique que possible. Mais la droite maintenant ce sont toutes les annonces et l'accès précoce afin que leurs déclarations Safe Harbor ne pas acheter sur ce qu'ils disent, seulement sur ce qu'ils ont actuellement.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top