構造と実装技術の選択
2009/06/24
トップダウンの原理主義的に考えるなら、構造や実装技術は、要件とIT要素を勘案してさまざまな選択肢から検討するわけです。
が、この企画はSilverlightとAzureでの業務アプリはどうなるのか、を考えているので、ほぼ実装技術は決まっています。
で、その実装技術が活かせそうな構造、というような、かなりボトムアップ的な?考えで決めていきます。
- 画面…Silverlight 3
- ロジック…WCFでホストされたXML WebServicesでAzure上に展開?
- データストア…SQL Services?それともAzure Storege Service?
ちょいと図にしてみましょう。
うーん、ステレオタイプの表現ができない(操作方法が見つからない)んでコメントで書く苦肉の策。
*コンポーネント*なんて書かなくても右上のアイコンで自明だからここにはステレオタイプを書かせてほしい。
なぜかVisualStudio2010betaでは配置図(パッケージ図)がかけないのでそこはJUDEで。
で、まあコンポーネント側は馴染み深い3層ですねと。
配置図で、なんでブラウザとAzureに同じのがあるんじゃと。無駄だと。エレガントさのかけらもないと。
ええ。本当にそう思います。
でも、この企画は泥臭い業務アプリの実現を目的にしていますんで、エレガントじゃなくなってます。
非機能要件の「ネットワークが切れているときも〜」系列を実現しようとすると、ブラウザ側にもロジックを持たざるを得ません。
ただ、思惑としては、どちらもC#のマネージドコードで、同一のロジック実装クラスを、かたや分散オブジェクト(同一ノードだから分散じゃないけど)のパラダイムでブラウザ内のSilverlightアプリ内に配置し、かたやメッセージングのパラダイムでWebServiceとして配置して、つまり実際のロジックが詰まっているクラスは、ブラウザだろうがWebServiceだろうが透過している、ということができる筈、というのがありましてね。
つまりWebServiceに置くはずのビジネスロジックのクラスをそのまんまブラウザ内部に置いて、しかもデータアクセスもクラウドの彼方とローカルPC内で透過してみたいということです。
LinqとDataSetでできそうな気がしているんですが。
というか、概念データベースに何気なくアクセスしてまうLinqがなかったら正直やろうと思わなかった気がする。
…いや、なんかもっとカッコいいスマートでクールでクレバーでジーニアスなブレークスルーあるのかな?
あとで気がついて地団太を踏む気もしますがまあいきましょう。
Bizのモデリング
2009/06/24
モデリングもなにもアンタ、単に台帳のCRUDだけじゃないか、と突っ込みたくなりませんか。
まったくそのとおりなんですが、ちょっとWF(Windows Worflow Foundation)といふものを使ってみんとてするなり。
とりあえず、メッセージングのパラダイムで考えるので、UX(って書いてますけどこの住所録じゃせいぜい「UI」)からファサード経由で伝票データを受け付けます。
このファサードはWebServiceとなってAzure上でホストされる予定です。…できるんだよな?(おい)
で、伝票データを受け付けたのをイベントとして、その伝票を処理するワークフローが実行されて、実際の住所録の台帳データが変更されるという感じです。
まだWFで動かしてもらうワークフローのクラスがなにをどう実装すればいいのかわからないので「WFで必要な何か」とか書いてますが、実装を進めていくうちにあきらかになる…といいな。
ファサードから直接台帳にいくのは検索のときを想定しています。クラスじゃなくて「台帳インターフェース」側に伸ばすべきかな。
まああんまり汎用性を考えているわけでもないですが…。
さて、とりあえず、だいたいの構造と、どう実装しようかという方針はきまったかなと。
データのところをどうするか(SQL ServiceなのかAzure Storegeなのか)がまだなんですが、私もまだどっちがいいか決めかねてます。
既存のSQLを使ってるコードならSQL Serviceのほうが親和性高いんですが、クラウドでスケーラビリティとか考えるとAzure Storegeのほうがいい感じがあります。
どうせ1からコードを書くので、Azure Storage側でいこうかな…というくらいのノリで考えてます。
いよいよ次は…画面の設計(まだ設計かよ!)
でも、設計といってもBlend使ったりするんで、プロトタイプ的なもの?になるかなと思ってます。