現在、 Force.comプラットフォームを開発プラットフォームとして使用することを検討しており、セールス担当者と force.com Web サイトには、Force.com が世界最高のプラットフォームである理由がたくさんあります。ただし、私が探しているのは、そのようなプラットフォームを使用することの実際の欠点です。
質問する
41093 次
9 に答える
142
ここにあなたが始めるための10があります.
- Apex は独自の言語です。force.com Eclipse プラグイン以外には、リファクタリング、コード分析などの利用可能なツールはほとんどまたはまったくありません。
- Apex は Java 5 でモデル化されていますが、これは他の言語に遅れをとっていると考えられており、ツール (#1 を参照) なしでは非常に扱いにくい場合があります。
- 展開は、多くの落とし穴や手動の手順があり、依然としてかなり手動です。この状況は時間の経過とともにゆっくりと改善されていますが、自動化された展開に慣れている場合はがっかりするでしょう.
- Apex にはパッケージ/名前空間がありません。すべてのクラス、インターフェイスなどは、サーバー上の 1 つのフォルダーに存在します。これにより、名前の衝突を回避し、コンテキストを提供するために、コードが整理されなくなり、クラス/インターフェース名が必然的に長くなります。これは私の最大の不満の 1 つであり、この理由だけで force.com を自由に構築することはできません。
- 「force.com IDE」、別名 force.com Eclipse プラグインは、信じられないほど遅いです。クラスファイル、テキストファイルなどのファイルを保存するには、組織内のオブジェクト、データ型、クラスファイルなどの数に応じて、通常は少なくとも 5 秒、場合によっては最大 30 秒かかります。保存もブロック アクションであり、コンパイルだけでなく、ローカル プロジェクトとサーバーとの完全な同期が必要です。Java や .NET より桁違いに遅い。
- オンラインの開発者コミュニティはあまり健全ではないようです。多くのフォーラム投稿が未回答または未解決になっていることに気付きました。これは、salesforce.com が使用しているフォーラム ソフトウェアと関係があるのではないかと思います。
- Apex のデータ アクセス DSL には、多くの要望が残されています。(N)Hibernate や JPA などとの競争力さえありません。
- Apex/VisualForce でアプリを開発することは、ガバナー リミット エンジニアリングの演習です。プログラマーの時間の半分は、多数のガバナー制限や、visualforce ビュー ステート制限などのその他の問題を回避するための最適化に費やされます。最初から効率的なコードを作成すれば、この問題は発生しないと主張することもできますが、これはある程度真実です。ただし、セッションで x 個を超えるクエリを作成したり、x 個を超えるレコードをループしたりする正当な理由がある場合がよくあります。
- 保存 -> コンパイル -> 実行サイクルは非常に遅いです。CSS や JavaScript のマイナーな変更をテストするためだけに、静的リソース バンドル全体を圧縮してアップロードする必要がある場合。
- 一般に、オープンソースであることの利点がなければ、若くて駆け出しのプラットフォームの痛みです。プラットフォームのバグを検証および/または修正する方法がありません。彼らはそれを IdeaExchange に投稿するように言っています。ええ、それで頑張ってください。
免責事項/開示事項: force.com などのホスト型プラットフォームには多くの利点があります。Force.com は定期的にプラットフォームを強化しています。それについては、私が好きなことはたくさんあります。force.com でお金を稼いでいます
于 2009-11-03T21:09:27.443 に答える
38
いくつかの回答が得られたようですが、プラットフォームのさまざまな知事の制限を回避するためにどれだけの時間が無駄になっているのかを繰り返し述べたいと思います。私は特定のレベルのプラットフォームが好きですが、一般的なアプリケーション開発プラットフォームとしては、非常に強く、強く、強くお勧めします。それが必要な場合は、超構成可能で拡張可能なCRMアプリケーションとして最適です。彼らのマーケティングは、一般的な開発プラットフォームとしてのForce.comのアイデアを推進する上で並外れたものですが、まだ遠く離れたところにさえありません。
安定したプラットフォームを持ち、大きなパフォーマンスと安定性の問題を回避することの効率は、人々が参照する制限の周りでコーディングしようとすると簡単に無駄になります。プラットフォームには非常に多くの制限があり、それは完全に腹立たしいものになります。これらの制限は、ユーザー数が多い場合に適用される上限ではなく、ほぼすぐに適用されます。
通常、それらを回避するための手法がありますが、実際のアプリケーションのビジネスロジックを開発しようとしているときに、それらを回避するための戦略を理解することは非常に困難です。
開発者が環境にどれほど不親切であるかを簡単に理解するために、上記の「デバッグ環境の欠如」を取り上げてください。それより悪いです。デバッグログには、サーバーへの最新のリクエストのうち最大20個しか表示されません。したがって、アプリケーション内で開発しているときに、「新規」デバッグリクエストを作成し、名前を選択して「保存」をクリックし、アプリに戻ってページを更新し、[デバッグ]タブに戻って、検索してみてください。デバッグログを格納するリクエストで、「検索」をクリックして、探しているテキストを検索します。デバッグ出力を確認するのに10回クリックするようなものです。些細なことのように思えるかもしれませんが、これは開発者の経験にほとんど注意と配慮が払われていないことのほんの一例です。
開発プラットフォームに関するすべては、後から付け加えられたものです。それが何であるかは注目に値しますが、ほとんどの場合、トータルPITAです。自分が何をしているのか正確にわからない場合（認定を受けており、Apexを非常によく理解している場合など）、別の環境で行う場合の10〜20倍の時間が簡単にかかります。あなたがまったく成功することができれば、それは途方もなく単純であるように思われる何か。
知事の制限は確かにそれほど悪いです。さまざまな制限（データベースクエリ、返される行、「スクリプトステートメント」、将来の呼び出し、コールアウトなど）の組み合わせがあり、これらを回避するために何をしているのかを正確に知る必要があります。たとえば、オブジェクトに計算されたロールアップ「数式」フィールドがあり、子オブジェクトにトリガーがある場合、親オブジェクトのトリガーが実行され、制限に対してカウントされます。そのようなことは、試して失敗するという苦痛なプロセスを経るまでは明らかではありません。
ある制限を回避するために1つのことを試み、「制限を打ち負かす」という終わりのないゲームで別のことを打ちます。その過程で、アプリ全体とアプローチを大幅に再構築し、すべてのテストコードを書き直す必要があります。本番環境にデプロイするには、75％のテストコードカバレッジが必要です。これは実際には非常に良いことですが、他のすべての制限と組み合わせると、非常に負担が大きくなります。実際には、通常のユーザーシナリオでは表示されないテストコードを記述してガバナーの制限に達しますが、それではカバレッジを達成できなくなります。
それは他の多くの問題は言うまでもありません。パッケージングはあなたが期待するものではありません。組織の管理者の側でユーザーの多大な介入と構成を行わずに、アプリをパッケージ化してユーザーに配信することはできません。AppExchangeは完全なジョークであり、アプリをリストに載せるためだけに5Kの課金を開始しました。特にトリガーがある場合は、データローダーを使用してインポートするのは面倒です。関係を含むすべてのデータを1つのステップでエクスポートして、1つのステップで別の組織（たとえば、開発組織）に簡単に再インポートできるようにすることはできません。サンドボックスを更新できるのは本番環境から月に1回のみで、例外はありません。アカウントエグゼクティブに電話してその機能のロックを解除しない限り、デフォルトでデータを更新に含めることはできません。あなたはできる' tカスタムオブジェクトのデータを一括削除します。パッケージ名は変更できません。特定のものは多くかかることがありますアプリをデプロイする前のデータバックアップなど、リクエストしてから完了するまでの日数。進行状況レポートはなく、エクスポートがいつ正確に行われたかについてはあまりわかりません。データ間に関係がある場合、データの同期性の問題があることを考えると、単一のステップで多数のオブジェクトをエクスポートできる「トランザクション」などがないという点で、深刻なデータ整合性の問題があります。これを容易にするための商用ツールはおそらくいくつかありますが、これらは莫大な予算を持っていない可能性のある通常の開発者には届きません。
他の人々がここで言った他のすべては真実です。ファイルの保存には、5秒から1分かかる場合があります。
プラットフォームはいくつかの点で非常にクールであり、他の誰もしていないマルチテナント環境で何かをしようとしているので、私はそれほど否定的であるという意味ではありません。これは非常に革新的な環境であり、いくつかのレベルで強力です（私は実際、VisualForceが大好きです）が、もう1、2年は与えてください。彼らはVMwareと提携しているので、開発者は刑務所の独房ではなく、もう少し遊び場を利用できるようになるかもしれません。
于 2010-04-24T00:02:07.507 に答える
25
過去 2 週間程度でプラットフォーム上での開発にかなりの時間を費やした後、私が提供できるいくつかのことを以下に示します。
RESTful API はありません。それらには、呼び出すことができる SOAP ベースの API がありますが、真の安らかな呼び出しを行う方法はありません
SObject を取得して JSON オブジェクトに変換する簡単な方法はありません。
視覚的な力のページは、カスタマイズするまでは問題ありませんが、その後は苦痛の世界です.
Visual force ページは SObject にバインドする必要があります。そうしないと、datepicker や選択リストなどの標準入力フィールドを機能させる方法がありません。
自分で作業したい場合はEclipseプラグインで問題ありませんが、Eclipseプラグインを使用して大規模なチームで作業したい場合は忘れてください. サーバーとの同期を処理せず、クラッシュし、まったく役に立ちません。
デバッガーはありません！デバッグしたい場合は、system.debug ステートメントによって文字通りデバッグされます。これはおそらく私が見つけた最大の問題です
彼らの「MVC」モデルは実際には MVC ではありません。ASP.NET Webforms に非常に近いです。ビューは、モデルだけでなくコントローラーにも密接に結合されています。
大量の文書を保管することは現実的ではありません。100 GB を超えるドキュメントを保存する必要があり、ばかげた数字が引用されました。ドキュメント ストレージを Amazon S3 インフラストラクチャに実装することにしました
言語は Java ベースですが、Java ではありません。外部のパッケージやライブラリをインポートすることはできません。また、利用可能なベース ライブラリは非常に限られているため、多くのものを外部で実装し、それらのビットを force.com によって呼び出されるサービスとして公開していることに気付きました。
外部の SOAP または REST ベースのサービスを呼び出すことができますが、メッセージ本文は 100 KB に制限されているため、呼び出すことができるものは非常に限られています。
正直なところ、force.com プラットフォームのようなもので開発することには潜在的な利点がありますが、私にとっては、force.com プラットフォームを真のエンタープライズ レベルのアプリに使用することはできませんでした。せいぜいいくつかの基本的なcrudスタイルのアプリケーションを書くことができますが、リモートで複雑なものに移行すると、疫病のようにそれを避けます.
于 2009-12-10T12:35:27.530 に答える
14
うわー-ここには、制限があることさえ知らなかったことがたくさんあります-プラットフォームで数年間働いた後.
しかし、他のいくつかのことを追加するだけです...
行ごとのデバッガーがないのは、まさにそれがマルチテナント プラットフォームだからです。少なくとも SFDC はそう言っています。スレッドが豊富なプログラミングのこの時代では、それは言い訳にはなりませんが、それが理由のようです。コードを書かなければならない場合、デバッガーとして「System.debug(String)」があります。約 12 年前に Java 1.2 でより洗練されたサーバー デバッグ ツールを使用したことを覚えています。
このシステムで私が本当に嫌いなもう 1 つの点は、バージョン管理です。Spring フレームワークは、Spring が通常使用される目的には使用されません。実際には、バージョン管理というよりも、SFDC の構成ツールから離れています。SFDC は ZERO バージョン管理を提供します。
たとえば、SFDC レポートを CSV ファイルにエクスポートして受信者のリストに電子メールで送信するようにスケジュールを設定するなど、非常に簡単なはずの作業に何日もかかってしまうことがあります。ワークフロー ルールと Visualforce 電子メール テンプレートを使用して、カスタム フィールドを使用してカスタム オブジェクトを作成します。次に、コードとして、レポート データを Visualforce 電子メール テンプレートに添付ファイルとしてストリーミングする Visualforce コンポーネントを記述する必要があり、匿名 APEX を記述します。カスタム オブジェクトのコード スケジュール フィールド更新... SFDC 開発者にとって、これはほぼ毎日のタスクです... 5 つの異なるテクノロジを組み合わせて、非常に単純に見えるタスクを実行しようとしています.... そして、これは管理上の頭痛の種になる可能性があります。そして緊張も - 通常、これは、そうでないことをするように提案された後にわかります。ユーザー コミュニティで機能しない (誰かが既に言ったように) し、多くのことを試してみると、それらを開発した後、奇妙な理由で機能しないことがわかります。 VisualForce ページ」、「スケジュール可能なコンテキストから getContent を呼び出すことはできません」、またはその他の難解な理由です。
SFDC プラットフォームには非常に多くの非常に多くの厄介な落とし穴があります。それらが存在する理由を理解すれば、それは理にかなっています。これが私のものです。
ほとんどすべての種類のレコードでレコード所有者情報を「すぐに」取得することはできません。レコードの作成時に所有者を挿入するレコードにリンクするトリガーを作成する必要があります。なんで？所有者は「人」または「キュー」のいずれかであり、2つはまったく異なるエンティティであるため、短い答えです...理にかなっていますが、プロジェクトを文字通り逆さまにする可能性があります。
狂気のセキュリティモデル。例: 「公開レポートの管理」権限は「レポートの作成とカスタマイズ」とは大きく異なり、基本的にプラットフォーム上のすべてのもの、特にあらゆる種類のフォルダーに適用されます。
前述のとおり、サポートは基本的に存在しません。あなたが非常に自給自足の個人である場合、または多くのSFDCリソースを持っている場合、または多くの時間があり、非常に寛容なマネージャーがいる場合、または正常に機能しているSFDCシステムを担当している場合、あなたはかなりうまくいっています.形。これらの立場のいずれにも属さない場合、深刻な問題に直面する可能性があります。
SFDC は非常に魅力的なビジネス提案です... 機器のフットプリントがなく、かなり優れたセキュリティがあり、固定価格で、インフラストラクチャがなく、バッチ処理とスケジュール処理が可能な Web ベースの CRM を利用できます... しかし、他の投稿者が言ったように、それは本当に開発学習のかなりの増加であり、コンサルティングを利用する場合、私が見た最低価格は 200 ドル/時間だったと思います。
Salesforce は、いくつかのテクノロジーが一般的になった数年後に他のものと統合する傾向があります。JSON と jquery が思い浮かびます。JIRA など、他の一般的なインフラストラクチャと統合したい場合は、多くの追加料金がかかることを期待してください。そして、それらは非常にバグが多い可能性があります。
そして、他のポスターの1人が言及したように、あなたは常にあなたを狂わせるガバナー制限と戦っています...添付ファイルは5MBを超えることはできません. 限目。また、3MB 未満の場合もあります (base64 でエンコードされている場合)。クラス内の 10 個の HTTP コールアウト。限目。公開されているガバナ制限は数十ありますが、そうでないものも多く、間違いなく見つけて、叫び声を上げてオフィスを使い果たしたいと思うでしょう。
私はプラットフォームが本当に、本当に好きですが、私を信じてください-それは本当に残酷な愛人になる可能性があります.
しかし、SFDC に公平を期すために、私はこれを言いたい: プラットフォームで私が見つけた最大の問題は、プラットフォーム自体ではなく、プラットフォームを見ているが開発していないほとんどの人が持っている巨大な期待です....そして、それらの人々は、ビジネス組織で大きな権限を持つ立場にある傾向があります。マーケティング、セールス、マネジメントなど。巨大な切断が発生し、頭が回転するか、毎日回転する恐れがあります.彼らはただしませんし、しません。
EDIT：
MVCに関するlomaxxのコメントに追加するだけです。SFDC の用語では、これは「ビューステート」と呼ばれるものと密接に関連しています。また、VF ページにあるものがページのコントローラー クラスにあるものではないという点で、非常にバグがある可能性があります。そのため、「保存」ボタンをクリックしたとき (または HTTP コールアウトなどを作成したとき) に、ページ上の内容とコントローラーが SF に書き込む内容を同期させるために、奇妙な回転を行う必要があります。 .
于 2013-02-04T19:13:35.217 に答える
7
他の人が不利な点をより深くカバーしていると思いますが、私には、MVCパラダイムを使用していないか、コードの再利用の方法をあまりサポートしていないようです。単純なアプリケーション以外のことを行うことは、ASP.NetMVCのようなものを使用してアプリケーションを開発することと比較してフラストレーションの練習です。
さらに、ツール、データレイヤー、および開発プロセス中にコードをリファクタリングしたりフィールドの名前を変更したりすることへの不満は役に立ちません。
CMSとしてはかなりクールだと思いますが、CMS以外のアプリケーションのプラットフォームとしては、私には意味がありません。
于 2010-09-08T14:44:10.323 に答える
6
Force.comが「クラウド」プラットフォームであることを考えると、外部のWSDL定義サービスのクライアントとして機能するその機能はかなり圧倒的です。最終的に何をしなければならないかについては、 http：//force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/を参照してください。
于 2010-05-22T17:59:23.113 に答える
6
セキュリティ モデルも非常に制限的です... しかし、これは最悪の部分ではありません。現在、ユーザーが特定のアクションを実行できるかどうかをアサートすることはできません。
その役割を確認することはできますが、その役割に現在のアクションを実行する権限があるかどうかを確認することはできません。
さらに悪いのは、技術サポートからの「アクションを試して、例外がある場合はそれをキャッチする」という応答です。
于 2009-12-12T10:28:18.053 に答える
3
上記のすべてに対して、VMforce のリリースにより、Java プログラマーが Force.com のコードを記述できるようになったことで、上記の欠点がどのように変わったのか興味がありますか?
http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071
于 2010-10-22T18:16:05.573 に答える
3
これらの問題に対処しようとしていると思います。Dreamforce では、ガバナーの制限を 4 に下げようとしているとのことでした。詳細はわかりません。アーリー アクセス用の REST API があり、クラウドでの Ruby 開発である heroku を購入しました。彼らは database.com でデータベースを分割するので、database.com を使用してすべての Web 開発と db 呼び出しを行うことができます。
彼らはそれを可能な限り不可知論的にしようとしていると思います。しかし、現時点では、これらはすべて発表と早期アクセスであるため、セーフハーバーの声明は、彼らの言うことではなく、現在持っているものだけで購入されます.
于 2010-12-28T18:51:52.373 に答える