SIerの視点で語る.NETテクノロジ…(ﾟДﾟ)？…に関するフォローを少し
昨日は割と脈略の無いことを書いた感もあるので、少しだけフォローを。
脈略の無いところをフォローというよりも、個々のテクノロジ/フレームワークのとらえ方についてですが。
自分の場合、MS系とかJava系というこだわりのある仕事環境には無い*1ので、嫌ホゲホゲというのはあまり無いつもりではいますが(´д｀;)
まあ、TPOに併せてスーツもアロハも着るという感じなので、テクノロジを比較する面は多くて。
それ故に、TPOとコーディネートのアンマッチが気になったり、人がズレた事言ってんな〜と思ったりという事があるわけですが(・ω・)
っで、.NETテクノロジについては、色々なフレームワークの中で現実解に近いというか、癖無く対応可能な範囲が広いと考えているわけです。
逆に言うと、他のテクノロジについては、特定コンテキストのみに特化したものが多いと言うことで(・ω・)
わかりやすい例としては、いわゆるWeb系の場合、Railsな考え方は非常に現実解である、っとかね。
もちろん、特定コンテキストに強いわけでなく、「フレームワークが強要する癖の悪さ > そのフレームワークが解決する課題」になっちゃってるものも多いんですが(´д｀;)
っで、以下、個別のテクノロジの、自分的なとらえ方とかについて。
Web Formsのとらえ方
たまに、ASP.NET Web Formsをビジュアル開発環境ととらえている人がいますが。
まあ、VB(6)からWebへ、っていう時に、わかりやすさとかプロモーションのしやすさで喧伝されてしまい、そう勘違いしたままの人がいるのは仕方がないですが(´д｀;)
Web Formsの正しいとらえ方は、コンポーネント指向のWebフレームワークだよね(・∀・)？、つって。
aspxの編集にデザインモードなんてほとんど使わないしぃ。
ソース表示というか、いっそアウトラインエディタでもいいくらいなんだけど。
っで、ページドリブン/コンポーネント指向のフレームワークと、MVC型のフレームワークは相反するものではなくて、得意とするコンテキストが違うっていうのはもう今更で良いよね(・ω・)？
コンポーネント指向のフレームワークという話では、Java好きな人なら、WicketやClick良いよね〜、という意見の人も多いと思うし(・∀・)
っで、JSFについては次。
JSF
仕様の細かい所が(検閲削除)。
個別の実装が(卑語削除)。
微妙なものを作るより、いっそのことWeb Formsをまる(以下略)。
まあ、ADFとかは、そう悪くも感じないんだけど(・ω・)
もちろん、コンテキストを限定して、深く考える必要が無いときの話というのは前提で。
あと、余談だけど、これはいまいちネタの域を出ない感があったりして(´д｀;)
http://dev.mainsoft.com/Default.aspx?tabid=177
After Rails型MVCフレームワーク
MVC云々の定義とかは、マンドクライのでバッサリ省略(´д｀;)
観点を、After Railsかどうかのみにおく事とします。
っで、Afterを.NET風味にスッキリしあげたのがASP.NET MVC(｀・ω・´)
Javaではどうかと言えば、Railsの影響を受けてMVCをイイカンジに再構築したモノがあるにはあるのだけれど、どうしても「自分たちで使う範囲では問題ありません」の領域を出ないというか、広く流行ってはいないのが悲しいところ(´・ω・`)
Strutsの呪縛は強いのだ(´д｀;)
仕方がないので、アノテーションを使って無設定化とか、ミクロなレベルでの改善をしてお茶を濁すわけですが。
まあ、それ以前に、その内容だったらむしろコンポーネント指向のフレームワークを使えというか、色々と無駄すぎる事をやっている現状を顧みてショボーン(´・ω・`)
∧ ∧ (,,ﾟДﾟ) おまえのやっている苦労、対して意味ないからな / | 〜（,,＿/
∧ ∧ (,,ﾟДﾟ) おまえのやっている努力、方向を間違っているからな / | 〜（,,＿/
…なんか懐かしい…。
ついでにPHPとかのRails型フレームワークについて。
SI屋的なニーズから見ると、この手のフレームワークはコンテキストを絞り込み過ぎている感が部分があると思うのよ(・ω・)
SI屋の視点に限らずとも、よく掲示板とかで、フレームワークの使い方について、SQLやHTTPレベルでの操作なら一発で終わるところを、時間をかけて質疑応答している状況を見たりすると、この人余裕あるな〜(ﾟДﾟ)、とか思わないではない。
っで、結局どうなるかと言えば、のりは自前で作って、ZendやPEARを部品として使う(その他のフレームワークのヨサゲな所は部分的にパクってくる)という選択をしている人たちも少なくないんじゃなかろうか。
……唐突に思ったのだが、PACはフレームワーク設計者が考えること、BCEはアーキテクトが考えること、MVCは一般論、っという言い方はどうだろうか？
っで、Presentationについては以上。
以下、Persistenceについて(・∀・)
Entity Framework*2
端的に言えば、これを一般解にするのはどうかと思うのよ。
LINQ to SQL
っと言うか、概念モデルではなく、(注:SQLを意識した、ではなく)ERモデルを意識したPersistenceフレームワークという方向性が少なく感じるのはなんでだろう(・ω・)？
RDBのテーブルに対応する[容れ物]/[メタデータ]クラスを使用して、柔軟なクエリの生成/発行ができるという方式のニーズは強いと思うのだけれど。
っで、そういう方式の現状最高峰がLINQ to SQL(｀・ω・´)
っというのが自分的なLINQ to SQLのとらえ方。
まあ、この方式で「柔軟なクエリ」を実現するには、言語レベルで色々なサポートが必要なので、仕方がない面があるのは既に日記に書いたことだけど。
あと、もう少し広い言い方をすれば、LINQと言われて何を想像するかと言われれば、Expressionsと答えるのが自分的なとらえ方。
to Objectとかはとりあえず置いてオク(´∀｀)
SQL外だし
っで、Persistenceの現実解についてに言えば、SI屋的ニーズと諸々のバランスを考えたときに、SQL外だし型のR/O Mapperを使っているケースも多いのでは無いかと思う次第(・ω・)
この方面についてはJavaが進んでいる感じで、生産性の高いフレームワークがあったりしてね(・∀・)
まあ、最悪のケースでもiBATISくらいは使うよという方向で。
1開発者からの視点で見ると、ベタなやり方ではなくて、もっと別のフレームワークを使いたいんだけどな〜、と思う事もあるでしょうが。
そこはまあ、業務用件、プロジェクトの規模、開発期間、要員、学習コスト、会社間のしがらみ(笑)、そういったものまでひっくるめて考えて、別のアーキテクチャを提案して効果を説明できるのであれば、アーキテクトやエロい人も、そのフレームワークの採用にNoとは言わないと思うけどね(・ω・)
っというか、そういうことはどんどんするべきだと思うのよね。
まとめ
っというわけで、昨日の日記にはあまり個々のフレームワークがどうこう的な話は書かなかったんですが。
昨日の内容は、上記のような考え方をベースにしているものと言うことでヨロシコ(・ω・)ノ
