FC2ブログ
 

Technology へようこそ
ここは技術者の「経験」と「ノウハウ」のブログです


--年--月--日

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


2009年07月17日

Silverlightによる業務アプリ開発

個人的には5ヶ月前くらいに初めて触ったSilverlight。
先日社内のメンバで少しだけ腰を据えてSilverlight製の業務アプリデモを作成しました。
デモといっても、一応Webサービス(WCF)経由でSQLServerからデータを取得するところまで実装しているので、単なるハリボテではなく、実際に触って動かせるレベルまで仕上げたものの、いかんせん開発主体の会社ゆえ、デザイン的にはどうなのよ、といった感が否めず…。
まぁ、それはともかく実際にやってみて感じた話をツラツラ書いてみます。

ビジネス的には「業務アプリに本当にRIAが必要なのか?」というところから議論を始める必要があるかとも思いますが、ひとまずその辺はさておいて、技術的な面で現状の課題を考えると、ひっかかっている点は以下の通り。

・データの受け渡し

前回の記事でも少し触れていますが、やはりDBMSとの接続方式は考えどころのようです。
単純にDataSetが使えれば良いのですが、Silverlightの標準ランタイムには非搭載なので、「WCF」や「ADO.NET Data Services」、あるいは今となってはちょいレガシー気味なのかもしれない「ASP.NET XML Webサービス」といったアーキテクチャを利用してXMLベースのWebサービスでデータをやりとりする形にせざるをえません。
「.Net RIA Services」という得体の知れない新顔もいるようですが、こちらはN層形態を実現するためのもののようです。(詳細は未調査)
従来型のアプリでは、UI(Webの場合はサーバコンポーネント)から直接クエリを投げるか、あるいはストアドプロシージャを呼び出すか、のいずれかで、結果セットはDataSet(DataTable)一本でいけていただけにこの違いはかなりインパクトがあります。

今回のデモでは、WCFに対してUIからクエリを投げて、結果として受信したXMLデータをクライアント側で配列展開するという若干インチキ臭い手法で実装しましたが、これはそもそもO/R的な考え方がウチの会社的に馴染んでいない(格好良く言えば、クエリ熟練者が多いため、あえてオーバーヘッドがかかるであろうO/Rマッピングを使う必要性を感じない)ためで、Javaで各種フレームワークを利用した開発をメインでやっている技術者の方などから見ると逆に不自然かもしれません。
今回は時間的な制約もあり、従来的な考え方の元に作り込んでしまいましたが、本来であればLINQを取り入れてO/Rマッピング的な手法を使っていく必要があるのかもしれません。
いずれにしても、業務アプリの場合、データベースアクセスは原則必須なので、これについては最重要検討課題。

・XAMLとコードビハインド

今回、XAMLについてはExpressionBlend2で大枠を作り、細かい調整をVisualStudio2008上で行う形を採りましたが、レイアウト周り(特にGrid)については多少慣れが必要です。
また、コントロールの見栄えや挙動を設定するためのテンプレートやスタイルも記述の仕方が分かりにくく、対象とするコントロールが変わるたびにとまどってしまいそうです。
かといって、これらを利用しないことには従来然としたルックスのコントロールしか使えないので避けて通ることはできません。
アニメーションを実現するための仕組みもなかなかに複雑で、Blendベースで事前定義するだけならば難しくないものの、自力でXAMLコードを書こうとしたり、コードビハインドで制御しようとしたりした瞬間、敷居はグンと高くなります。
さらにはデータ連携するためにバインディングの知識も必須となっており、こちらもしっかり押さえておく必要があります。
いずれにしても、Windowsフォームアプリとは全く違う感覚ですし、どちらかというとHTML+CSS+JavaScriptをひとつにまとめたような代物なので、C/Sアプリを中心としてやってきた技術者がとっつきにくいのは間違いありません。
よくもまあこんな仕組みを考えるもんだ、と感心しきりですが、ぶっちゃけもう少し開発しやすい環境が欲しいところ。

で、コードビハインドですが、まず悩ましいのが、どこまでをXAMLで書いて、どこからをコードで実装するかの切り分け。
ウリとして「デザイナと開発者が分業できる」などと謳ってはいますが、実際のアプリを作る上でこれはなかなかに難しいわけで、やはりとっかかりを作る意味でも最初は開発サイドがデザイン周りも含めて規約やガイドラインのようなものを策定していかざるをえないのではないかと思われます。
手っ取り早いのは開発者がデザイン込みで作ってしまうことなのでしょうが、それができる人間はかなり限られた人種ではないかと…。

ちなみに今回、Silverlight ToolkitのChartコントロールを使ったのですが、グラフ系列(Series)や軸(Axis)などもXAMLベースで記述することができる一方、場合によっては動的にインスタンスを生成/削除しないとうまくハンドリングできないケースなどにも遭遇したりして悩まされたわけですが、統一性を考えると融通の利く動的生成を採用したくなるものの、デザインの分離という側面で考えると一概にごっそりコード側に移すのもどうかと思うわけで…。
テンプレートをリソース定義しておけば解決するのかもしれませんが、テンプレートをコード側から操作するのがこれまたなかなか難儀そうで、この辺りも今後の課題です。

と、まぁ大雑把にはこんなところでしょうか。
細かいことを書き出すとキリがないので、今回はこれくらいにしておきます。



最後にビジネス的にひとつだけ言えるのは、RIAはコスト的にはメリットがあまりないであろう、ということ。
従来手法よりも安く開発できるか、といったら確実に「それはない」と言えます。
なぜならデザインコストが余分に乗ってくるから。
実装工数は経験を重ねてノウハウを蓄積することにより、従来手法とさほど変わらないレベルまで持っていけるかもしれませんが、デザイン周りについては完全に別腹扱いにせざるをえません。(デザイン費用をどう見積もるか、という問題はありますが)
従来型のデザインで良いのなら、C/SならWindowsフォーム、WebならHTML+CSSで事足りるわけですし、そのほうがコスト的には安上がりでしょう。
なにせ、出来合いのコントロールをフォームなりHTMLなりにポトペタするだけでオケなわけですし。
じゃあ、何がメリットなのかというところをきちんと考えようとしているのですが、これといった答えが見つからずにいます。
もちろんUI/UX的に優れたものが作りやすいという話はあるにはあるものの、「作りやすい」と「作れる」は実は同義ではなくて、それなりの経験とセンスが伴わなければ、RIA技術を使ったからといって必ずしもユーザに優しい、操作性の良いアプリケーションが作れるとは限らないのです。
むしろ、その辺りのセンスを持ち合わせた会社や人がいるのであれば、従来型でもそれなりに満足いくアプリケーションが作れるであろうことを考えると、尚更微妙な気すらしてきます。
個々のコントロールはこれまでにも存在していたものばかりです。
これらを発展的に組み合わせて使うだけで、はたしてコスト面での不利を払拭できるほどのアピールをユーザに対してできるのか?
なにやら最後に否定的な雰囲気になってきてしまいましたが、正直なところ、こうした懸念は少なからず存在します。
ただ、作っていて楽しいのは事実ですし、これまで以上に利用者の視点でデザイン/設計をしなければいかん、という暗黙のプレッシャーのようなものを感じられる意味において、RIAの利用は開発サイド、ユーザサイド双方にとって、益ある結果を導いてくれるかもしれません。
つい先日、次バージョンのMS Officeは無償Webアプリバージョンも提供されるというリリースが出ましたが、世の流れは確実にリッチUIなWebアプリに向いています。
まぁ、そういう意味では「こまけぇこたぁいいんだよ!」的なノリで、当たり前のようにRIAにシフトしていくのかもしれませんねw

[ posted by ken ]

この記事に対するコメント


この記事に対するコメントの投稿














管理者にだけ表示を許可する



この記事に対するトラックバック
トラックバックURL
http://comfair2.blog24.fc2.com/tb.php/428-da572be6
この記事にトラックバックする(FC2ブログユーザー)











上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。