最近では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的に提供される日がいつか来るんじゃないかと。