Force.comプラットフォームの欠点
現在、開発プラットフォームとして Force.com プラットフォームを使用することを検討していますが、営業担当者とforce.com Webサイトは、世界最高のプラットフォームである理由に満ちています。しかし、私が探しているのは、そのようなプラットフォームを使用することの本当の欠点です。
ここから始めましょう。
- 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個を超えるレコードをループしたりする正当な理由がある場合が多くあります。
- Save-> compile-> runサイクルは、特に非常に遅いです。ちょっとしたCSSやjavascriptの変更をテストするなどの目的で静的リソースバンドル全体を圧縮してアップロードする場合。
- 一般に、オープンソースであるという利点のない、若くて駆け出しのプラットフォームの痛み。プラットフォームのバグを検証および/または修正する方法はありません。彼らはIdeaExchangeに投稿するように言っています。ええ、幸運を祈ります。
免責事項/開示：force.comなどのホストプラットフォームには多くの利点があります。 Force.comは定期的にプラットフォームを強化しています。私の好きなことはたくさんあります。 force.comで収益を上げています
いくつかの回答が得られたと思いますが、プラットフォームのさまざまなガバナ制限を回避するためにどれだけ時間が無駄になっているのかを繰り返したいと思います。特定のレベルのプラットフォームが好きな限り、一般的なアプリケーション開発プラットフォームとして非常に強く、強く、強くお勧めします。必要に応じて、非常に構成可能で拡張可能なCRMアプリケーションとして最適です。彼らのマーケティングは、一般的な開発プラットフォームとしてのForce.comのアイデアを推進する点で非常に優れていますが、まだ近いものではありません。
安定したプラットフォームを持ち、パフォーマンスと安定性の大きな問題を回避することの効率は、人々が参照する制限を超えてコーディングしようとすると簡単に無駄になります。プラットフォームには非常に多くの制限があり、完全に腹立たしくなります。これらの制限は、多くのユーザーがいるとすぐにヒットする上限の制限ではありません。
通常、それらを回避する手法がありますが、実際のアプリケーションのビジネスロジックを開発しようとしているときに、それらを回避するための戦略を見つけることは非常に困難です。
開発者が環境にやさしくないことを簡単に理解するには、上記の「デバッグ環境の欠如」をご覧ください。それよりも悪いです。デバッグログには、サーバーへの最新のリクエストのうち最大20件しか表示できません。そのため、アプリケーション内で開発しているときに、「新規」デバッグリクエストを作成し、名前を選択し、「保存」をクリックして、アプリに切り替え、ページを更新し、デバッグタブに戻って、デバッグログを格納するリクエスト。「find」を押して、探しているテキストを検索します。デバッグ出力を見るために10回クリックするようなものです。些細なことのように思えるかもしれませんが、これは開発者の経験にほとんど注意と配慮が払われていないことのほんの一例です。
開発プラットフォームに関するすべては、後から付け加えられたものです。それが何であるかは注目に値しますが、ほとんどの場合は合計PITAです。自分が何をしているのかが正確にわからない場合（認定を受けており、Apexを非常によく理解している場合など）、別の環境で行う場合の10倍から20倍の時間を簡単に消費できますあなたがまったく成功することができれば、それは途方もなく簡単だと思われる何か。
ガバナーの制限は確かにそれほど悪いものです。さまざまな制限（データベースクエリ、返される行、「スクリプトステートメント」、将来の呼び出し、コールアウトなど）の組み合わせがあり、これらを回避するために正確にを知っている必要があります。たとえば、オブジェクトに計算されたロールアップ「式」フィールドがあり、子オブジェクトにトリガーがある場合、親オブジェクトトリガーを実行し、制限に対してカウントします。そのようなことは、試して失敗するという痛みを伴うプロセスを経るまで明らかではありません。
1つの制限を回避するために1つのことを試して、「制限を打つ」という終わりのないゲームで別の制限をヒットします。このプロセスでは、アプリとアプローチ全体を大幅に再設計し、すべてのテストコードを書き直す必要があります。 must実稼働環境に展開するためのテストコードカバレッジは75％です。これは実際には非常に良いことですが、他のすべての制限と組み合わせると、非常に面倒です。実際には、通常のユーザーシナリオでは発生しないテストコードを記述するガバナーの制限に達しますが、カバレッジを達成できなくなります。
それは、他の問題のホスト全体に言及するものではありません。パッケージはあなたが期待するものではありません。組織の管理者側でのユーザーの大幅な介入と設定なしでは、アプリをパッケージ化してユーザーに配信することはできません。 AppExchangeはまったくの冗談であり、アプリをリストアップするためだけに5Kを請求し始めました。データローダーを使用したインポートは、特にトリガーがある場合は非常に面倒です。関係を含むすべてのデータを1つのステップでエクスポートすることはできません。そのため、1つのステップで簡単に別の組織（dev組織など）に再インポートできます。サンドボックスは実稼働から1か月に1回のみ更新でき、例外はありません。また、アカウントエグゼクティブに電話してその機能のロックを解除しない限り、デフォルトでデータを更新に含めることはできません。カスタムオブジェクトのデータを一括削除することはできません。パッケージ名を変更することはできません。アプリをデプロイする前のデータバックアップなど、進行中の進捗レポートがなく、正確にエクスポートするタイミングがあまりわからないなど、特定の処理には多くの時間がかかります日発生した。データ間に関係がある場合、データの同期性の問題があることを考えると、単一のステップで多数のオブジェクトをエクスポートできる「トランザクション」のようなものがないという深刻なデータ整合性の問題があります。おそらくこれのいくつかを促進するいくつかの商用ツールがありますが、これらは巨大な予算を持っていないかもしれない通常の開発者には手の届かないところにあります。
他の人々がここで言った他のすべては真実です。ファイルを保存するのに5秒から1分かかることがあります。
プラットフォームがいくつかの点で非常にクールであり、彼らは他の誰もしていないマルチテナント環境で物事を行おうとしているので、私はそれほど否定的ではありません。これは非常に革新的な環境であり、いくつかのレベルでは強力です（私は実際にVisualForceが大好きです）が、さらに1〜2年は与えます。彼らはVMwareと提携しており、おそらくそれは開発者に刑務所のセルではなく、もう少しプレイペンを提供することにつながるでしょう。
ここ2週間ほどでプラットフォームの開発にかなりの時間を費やした後、私があなたに提供できるものをいくつか紹介します。
RESTful APIはありません。彼らはあなたが呼び出すことができる石鹸ベースのAPIを持っていますが、真の安らかな呼び出しを行う方法はありません
SObjectを取得してJSONオブジェクトに変換する簡単な方法はありません。
視覚的なフォースページは、カスタマイズするまでは問題ありません。その後、苦痛の世界が広がります。
視覚的な強制ページはSObjectにバインドする必要があります。そうしないと、datepickerや選択リストなどの標準入力フィールドを取得する方法がありません。
Eclipseプラグインは、自分で作業したい場合は問題ありませんが、Eclipseプラグインを使用して大規模なチームで作業したい場合は忘れてください。サーバーとの同期を処理せず、クラッシュし、まったく役に立ちません。
そこにIS NO DEBUGGER！デバッグしたい場合、文字通りsystem.debugステートメントによってデバッグされます。これはおそらく私が見つけた最大の問題です
彼らの「MVC」モデルは、実際にはMVCではありません。 ASP.NET Webformsに非常に近いです。ビューは、モデルだけでなくコントローラーにも密接に結合されます。
大量のドキュメントを保存することはできません。 100ギガバイト以上のドキュメントを保存する必要があり、とんでもない数字が引用されました。 Amazons S3インフラストラクチャにドキュメントストレージを実装することにしました
言語もJavaベースであり、Javaではありません。外部のパッケージまたはライブラリをインポートすることはできません。また、利用可能なベースライブラリは厳しく制限されているため、実装しています。大量のものを外部から取得し、それらのビットをforce.comによって呼び出されるサービスとして公開します
External SOAPまたはREST=ベースのサービスを呼び出すことができますが、メッセージ本文は100kbに制限されているため、呼び出すことができるものは非常に制限されます。
正直なところ、force.comプラットフォームのようなもので開発することには潜在的な利点がありますが、私にとって、真のエンタープライズレベルのアプリにforce.comプラットフォームを使用することはできませんでした。せいぜい基本的なクラッドスタイルのアプリケーションを作成することはできますが、いったんリモートで複雑なものに移行したら、ペストのようにそれを避けます。
うわー、ここに何年もプラットフォームに取り組んだ後、制限があるとさえ知らなかったことがたくさんあります。
しかし、単に他の何かを追加するために...
行ごとのデバッガーがない理由は、それがマルチテナントプラットフォームであるためです。少なくともそれはSFDCが言っていることです-スレッドリッチプログラミングのこの時代では、それは言い訳にはなりませんが、明らかにそれが理由です。コードを記述する必要がある場合は、デバッガーとして「System.debug（String）」を使用します。約12年前にJava 1.2でより高度なサーバーデバッグツールを使用したことを覚えています。
システムについて私が本当に嫌いなもう1つのことは、バージョン管理です。 Springフレームワークは、Springの通常の使用目的には使用されません。バージョン管理よりも、SFDCの構成ツールの方がはるかに役立ちます。 SFDCは、ゼロバージョン管理を提供します。
SFDCレポートをスケジュールしてCSVファイルにエクスポートし、受信者のリストに電子メールで送信するなど、非常に簡単に思えるような操作を何日も続けることができます。まあ、それを行う最も簡単な方法はカスタムフィールド、ワークフロールール、およびVisualforceメールテンプレートを使用してカスタムオブジェクトを作成します。その後、コードとして、レポートデータをVisualforceメールテンプレートに添付ファイルとしてストリーミングするVisualforceコンポーネントを記述し、匿名APEXを記述します。カスタムオブジェクトのコードスケジュールフィールド更新... SFDC開発者にとって、これはほぼ毎日の作業です... 5つの異なるテクノロジーを組み合わせて、非常に単純に見えるタスクを実行しようとしています。緊張も-通常、ユーザーコミュニティで機能しないこと（既に誰かが言ったように）を行う提案を取得し、それらを開発した後、あなたがしたい多くのことを試してからこれを見つけます彼らはいくつかのoのためにちょうど働かないことを見つけなさいDDボールの理由-「VisualForceページをスケジュールできない」、「スケジュール可能なコンテキストからgetContentを呼び出せない」などの不可解な理由。
SFDCプラットフォームには、ちょっとした落とし穴がたくさんあるので、なぜそこにあるのかを理解するのは理にかなっています...しかし、それはまだ、あなたがするべきことをするのを妨げる非常に悪い制限です。これが私の一部です。
ほとんどすべての種類のレコードについて、「すぐに」レコード所有者情報を取得することはできません。レコードの作成時に所有者を挿入するレコードにリンクするトリガーを作成する必要があります。どうして？短い答えは、所有者は「人」または「キュー」のいずれかであり、2つはまったく異なるエンティティであるためです...理にかなっていますが、プロジェクトを文字通り上下逆にすることができます。
狂気のセキュリティモデル。例：「公開レポートの管理」権限は、「レポートの作成とカスタマイズ」とは大きく異なり、基本的にプラットフォーム上のすべてのもの、特にあらゆる種類のフォルダーに適用されます。
前述のように、サポートは基本的に存在しません。あなたが非常に自給自足の個人であるか、または多くのSFDCリソースを持っているか、多くの時間および/または非常に寛容なマネージャーを持っているか、うまく機能しているSFDCシステムを担当しているなら、あなたはかなり良いです形状。あなたがこれらのポジションのいずれにも属していない場合、あなたは深い問題に直面することができます。
SFDCは非常に誘惑的なビジネス提案です...機器の設置面積、かなり良いセキュリティ、固定価格、インフラストラクチャはありません。また、バッチ処理可能な、スケジュール可能な処理を備えたWebベースのCRMを取得します...しかし、他のポスターが言ったように、それは本当に開発学習のかなりのランプアップであり、コンサルティングに行く場合、私が見た中で最低価格は200ドル/時間だったと思います。
Salesforceは、いくつかのテクノロジーが一般的になった数年後に他のものと統合する傾向があります-JSONとjqueryが思い浮かびます...そして、JIRAなどの統合を行いたい他の一般的なインフラストラクチャがある場合、追加料金を支払うことを期待し、そしてそれらは非常にバグが多い場合があります。
そして、他のポスターの1つで述べたように、あなたは絶えず知恵の限界と戦っています。期間。また、3MB未満の場合もあります（base64エンコードの場合）。クラス内の10個のHTTPコールアウト。期間。公開されているガバナーの制限は数十ありますが、その多くは間違いなく見つかり、オフィスの悲鳴を上げたいだけです。
私は本当にプラットフォームが本当に好きですが、私を信じてください-それは1人の本当に残酷な愛人になることができます。
しかし、SFDCに公平に言えば、私はこれを言うでしょう：私がプラットフォームで見つけた最大の問題は、プラットフォーム自体ではなく、プラットフォームを見ているが、その上で開発していないほとんどの人が持っている巨大な期待です...そして、それらの人々は、ビジネス組織において大きな権威の地位にある傾向があります。マーケティング、販売、管理など。巨大な切断が発生し、頭が回転したり、毎日回転するように脅かされたりします。彼らはそうしないし、しません。
編集：
MVCに関するlomaxxのコメントに追加するだけです。 SFDCの用語では、これは「ビューステート」と呼ばれるものと密接に関連しています-VFページにあるものはnotのコントローラークラスにあるという点で、実際にはバグがある可能性がありますページ。そのため、「保存」ボタンをクリックしたときに（またはHTTPコールアウトなどを行うときに）コントローラーがSFに書き込む内容とページの内容を同期させるには、奇妙な回転を熟知する必要があります。 。
他の人は欠点をより深くカバーしていると思いますが、私にとっては、MVCパラダイムを使用したり、コードの再利用の方法をあまりサポートしていないようです。単純なアプリケーションを超えて何かを行うことは、ASP.Net MVCのようなものを使用してアプリケーションを開発することと比較して、フラストレーションの練習です。
さらに、ツール、データレイヤー、および開発プロセス中にコードをリファクタリングしたりフィールドの名前を変更しようとすることに対するフラストレーションは役に立ちません。
CMSとしてはかなりクールだと思いますが、CMS以外のアプリケーション用のプラットフォームとしては、私には意味がありません。
セキュリティモデルも非常に制限が厳しくなります...しかし、これは最悪の部分ではありません。現在、ユーザーが特定のアクションを実行できるかどうかをアサートすることはできません。
ロールが何であるかを確認できますが、そのロールに現在のアクションを実行する権限があるかどうかは確認できません。
さらに悪いのは、「アクションを試行し、例外がある場合はキャッチする」という技術サポートからの応答です。
Force.comが「クラウド」プラットフォームであることを考慮すると、外部のWSDL定義サービスのクライアントとして機能するその能力は、かなり圧倒されます。 http://force201.wordpress.com/2010/05/20/when-generate-from-wsdl-fails-hand-coding-web-service-calls/ を参照してください。しなければならない。
彼らはこれらの問題に対処しようとしていると思います。ドリームフォースでは、知事の制限を4にまで下げようとしていると述べました。詳細はわかりません。アーリーアクセス用のREST APIがあり、クラウドでのRuby開発であるherokuを購入しました。 database.comを使用してデータベースを分割するため、database.comを使用してすべてのWeb開発とdb呼び出しを行うことができます。
彼らはできるだけ不可知論者になろうとしていると思います。しかし今のところ、これらはすべて発表と早期アクセスであるため、セーフハーバーの声明は彼らが言うことを購入せず、現在持っているものだけを購入します。
上記のすべてに対して、VMForceのリリースにより、JavaプログラマーがForce.comのコードを記述できるようになり、上記の欠点がどのように変わるのでしょうか？
http://www.zdnet.com/blog/saas/vmforcecom-redefines-the-paas-landscape/1071