最近ではMobileの波が来ていることもあり、jQueryだけでなくBackbone.jsやAngular.js等の
JSフレームワークを利用した開発サンプルもSalesforceから提供されるようになった。
既存のApexタグと同じくらいJavaScriptも使いこなせないとね、って感じ。
そこで、出てくるのがApexとJavaScriptとの使い分け。
ここらへんってApexだけじゃなくて、全てのサーバサイドプログラミング言語に共通していることで、
私が偉そうに言えることでも無いけど、とりあえず書いてみる。
まず、混在するパターンとしては以下のとおり
1. Visualforceページ開発におけるバリデーションチェックでの混在。
→JavaScriptによるチェックは、デプロイ不要なため手軽に利用でき、チェックにサーバへのアクセスが不要なため、ユーザビリティ的にも良いが、
JavaScript自体、書き換え可能なため不正な値がサーバにPOSTされる可能性がある。
一方、Apexによるチェックは、デプロイやテストクラスの修正が必要になるが、
サーバにPOSTされた値を検証するため、不正な値が来ても問題ない。
こうしたトレードオフにより、両者を併用することがセキュリティ的にはベストな実装。
デプロイ不要という手軽さ故、暫定対応的にJavaScriptのみのバリデーションを実装することが多いが、
飽くまでも暫定対応。
Apexによるチェックと書いたけど、入力規則をうまく使えば、サーバサイド（Apex）でのバリデーションチェックすらも要らない。
そもそもMVC的にはコントローラではなくモデルにバリデーションチェックを入れるべきだから、
入力規則やトリガに任せるのが一番良いんだろうけど…。
2. カスタムボタンのOnClickJSでの実装。
→これはOnClickJSでSOAP API(Ajax Tool Kit)を利用するパターンで、カスタムSOAP APIを作って、それを呼び出すパターンが良い実装。
Apexクラスであればテストクラスが利用できるし、色々と再利用も可能。
OnClickJSで標準のSOAP APIをごりごり使うのも良いけど、
APIコール数の消費を抑えたり、単体テスト自動化を実装するためにも
カスタムSOAP APIでのApexクラスの利用を考えたほうが良い。
っていうか、個人的にはカスタムボタン使うくらいだったら、
インラインVFでAPIコール無しに自由にJavaScriptとApexクラスで実装しようよって感じなんだけど。
3. ApexをREST APIとして利用して、
HTML5,JavaScriptでゴリゴリとアプリを書くっていうパターン。
→最近のWebアプリはこんな感じだと思うので詳細は割愛。force.comではRemoteAction(Salesforceが出しているライブラリとしてはremoteTK)を利用する。
どのパターンにおいても意識しないといけないことが「単体テストの自動化」ということ。
Apexクラスにはテストクラスと呼ばれるテスト自動化の仕組みがあり、比較的利用がしやすい。
一方JavaScriptの方は一般的なWebでの方法は確立されているものの、
導入の難易度が比較的高く、force.comでのテスト自動化が難しいように感じる。（OnClickJSとかでは特に）
アジャイル開発なforce.com開発において（というかアジャイルじゃなくても）テスト自動化は超重要事項。
salesforce側はMobileの波を受けて、JavaScript開発を薦めている感じだから
きっとJavaScriptのテスト自動化もsalesforce側で、つまりPaas的に提供される日がいつか来るんじゃないかと。
