中堅システムエンジニアの備忘ログ

20代後半SEによる、備忘を兼ねた技術的な記事メインのブログです。

SharePoint開発におけるAPIの選択(JSOM vs SSOM)

こんばんは。ねるおです。

 以前、SharePoint絡みの開発時に、こんなことでもめました。

JavaScript Object Model vs Server Side Object Model

とあるリストから最新○件のアイテムを一覧形式で表示したい。その機能をJSOMで作るべきか?SSOM(カスタムWebパーツ)で作るべきか?

※デフォのWebパーツはとある理由から却下でした。

 

どちらを選択するにせよ機能的に等価な場合、どちらで作るべきなんでしょうか。

性能的にはSSOMが有利か。

色々な意見が出ました。中でも決定的に見えたのはこの意見です。

 

・サーバーサイドでレンダリングするSSOMのほうが、クライアントから非同期でリストアイテムを取得し、その後にレンダリングするJSOMより性能で勝る。

 

みんな納得。その後、「基本的にはSSOMでカスタムWebパーツ開発だな。」という流れができかけました。

開発効率は圧倒的にJSOM

ねるおはSSOMは嫌でした。だって作るのだるいから。

開発効率は圧倒的にJSOMが勝ると思います。

Visual Studio使うのがだるい

SSOM(=C# or VB)を選択した場合、Visual Studioで開発せざるを得ません。

起動遅いし、色々よくわからない機能ついてて操作が難しいし、Visual Studio

好きくないんです。

その点、JSOM(=JavaScript)ならサクラエディタとか秀丸で十分!

デバッグするときの手順も、

 

 SSOM:[ソース保存]→[コンパイル]→(ぐるぐるウインウイン)→[デバッグ実行]→

     (ぐるぐるウインウイン)→[(ブラウザに)画面描画]→後はご自由に。

 JSOM:[ソース保存]→[(ブラウザに)画面描画]→[F12]→後はご自由に。

 

ぜんぜん違う!時間的に5倍くらい違うんじゃない!?笑

 やっぱりコンパイル言語とスクリプトではプログラム実行までの道のりが全然違いますな。

 

・・・みたいなことを力説したら、見事「JSOMでおk!!!」となりました。

めでたしめでたし。

Microsoft様もJSOM推してる。

SharePoint 2013 での適切な API セットの選択

を見ると、

 

SharePoint データに対して CRUD 操作を実行する HTML/JavaScript アプリケーションを作成する” 時は「JSOMでおk!!!」とバッチリ書いてありました。

(それより上に”ユーザーの既存スキルに合わせてAPI選択すべし。”ともありますが笑) 

まとめ

開発手法って次から次へと新しいものが生まれて、どんどん選択肢が広くなるんですよね。

3年前くらいにJSOMをはじめて知った時は「JavaScriptCRUD??意味不明。」と毛嫌いしていました。使ってみるとめちゃ便利!! 

 

日々情報収集 して勉強して行かなければ取り残されてしまうようで、怖い業界ですねT_T

 

 

ねるお。