JAX-RSを使ってみた、からの、フレームワーク的は話を少し
RIAなアプリケーションを作ることになって、クライアントはSilverlightで良いんだけど、サーバはLinuxでも動かすと言うことで。
どういう構成にしようかと検討した結果、とりあえずSpring+RESTEasyで進めてみるぽにしてみたのでした。
っで、JAX-RSを使ってみての感想を少し書いておきます(・ω・)
- 作者: Bill Burke,arton,菅野良二
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/08/23
- メディア: 大型本
- 購入: 28人 クリック: 804回
- この商品を含むブログ (40件) を見る
JAX-RS、Javaなフレームワークの中ではだいぶマシな考え方なんだけど、なんでRESTという範囲での話なのかしらね(・ω・)？、っというのがあって。
どうせならもう少し枠を広げて、Web MVC的な部分を含めてJava MVC的なものを規定すれば良いのに(・∀・)、っとか。
まあ、今回はAPIサーバを作るという目的だったので、事足りたんですが…(・ω・)
フレームワークを選ぶとき
今、JavaでWebアプリを作る場合に、プレゼンテーション層にどのフレームワークを選択するかという問題があって(´・ω・`)
まあ、フレームワークの選定作業というのは、純技術的な要素やシステム種別(イントラ事務系か、コンシューマ系かとか)以外にも、システムのライフサイクル、要員のスキルレベル、学習コスト、それに会社間の関係とかまで考慮するものですが。
とりあえずその辺の話はおいておくとすれば、Web MVC系のものに関しては、変に凝ったものよりも、シンプルかつ拡張ポイントで自由がきくものが欲しいというのが自分の希望(｀・ω・´)
モダンなフレームワークの構成
FilterでRoutingの処理をして、Model binding(http request, session, cookie, route data)、Validationを行い。
そのModelを引数にControllerを呼び出して、戻り(Navigation)によってView(jsp、xml、json、redirect、...)を選択するっと、…まあ、モダンなフレームワークはだいたい似たような構成をしていますが(・ω・) *1
自由がきくという意味では、処理は拡張ポイントを利用したPiplineになっていて、BindingやValidationもPluginとして構成されていて。
後は、AnnotationやDescriptorがあるという感じで(・ω・)
言い方を変えると、それだけ用意すればWebフレームワークなんて作れますよ、なんつって(・∀・)
Javaの場合、Commonsをどうするか(どこまで自前で用意するか。まあ、必要なのはDescriptor、Converter/Mapperくらいだけど)の問題もあるけど(・ω・) *2
っで、拡張ポイントがちゃんと設計できているものならば、Controller factoryに任意にコンテナを使ったり、独自のRenderingを行うViewの追加とかは簡単にできるので、そこはCoreから分離してExtensionで、みたいになっているのが理想かな。
…まあ、ぶっちゃけ、自分的にはASP.NET MVCのまんまコピーがあるのが一番嬉しいんですけどね、なんつって(・∀・;)
っで、自分の希望の話はおいておいて、現実的に今あるもので選択しろと言われたら、Spring MVC 3にしちゃうかも、っとか(・∀・;)
Java、JSRの仕様と実装の分離
あと、今更ながらになんだかな〜と思ったのが、Java、JSRの仕様と実装の分離について。
仕様を策定して、実装は分離すると言うことについては、例えばスモールデバイスのAPIだとか、エンタープライズミドルのAPIなんかについては意味があると思うわけですが。
でも、ぶっちゃけフレームワーク的なものでそれをやられても、無駄に複数の実装ができたり、実装毎の拡張仕様の違いがあったりだとか、面倒なだけだと思うんですよね(´・ω・`)
JAX-RSの話
そして話をJAX-RSに戻しますが。
拡張ポイント的な部分は弱いな〜と思いますた(´・ω・`)
あと、他のWebフレームワークにもありがちなんだけど、URLのパスをアノテーションで指定するんじゃなくて、ちゃんとしたRouterを作って欲しいと思ったり(´・ω・`)
パスパラメータの処理と、パスにマッチした時のハンドラへのディスパッチはRouting専門のFilterにやらせるべきで。むしろweb.xmlにはRoutingFilterのみを登録したい(｀・ω・´)、つって。
Java製のソーシャルっぽいWebアプリにありがちだけど、Url Rewrite Filterで色々ごまかすとかカコワルイ(´・ω・`)
パーシステント層についても
っで、プレゼンテーション層の話をしたんで、ついでにデータアクセスの話についても少し。
個人的には、データアクセスについては柔軟にやりたいんで、本当はArel的なSomethingが良いんだけどというか、(DBから作成した)式メタデータクラスを使ってクエリ構築する感じが希望ですが。
後、マッパー部分はGrouping対応を標準で用意してくれれば、自分的には事足りそうな予感もしますが(・∀・)
SQL外部化型のORMは小規模事務系には良いかもしれないけど、パラメータの有無による条件の有無とかが増えてくるとなんか面倒だし、それならいっそストアドにして結果だけマッピングするんで良いよと、思ったりもして(´д｀)
小規模データ(<10万)、限られたユーザ数であれば、ORMなんてなんだって良いよ、…等という堕落した思考も世の中にはありますが(´д｀;)
いや、トランザクションストラテジーの話はあるか、意図しての設計ならともかく、そこをルーズにはできないというSI脳(・ω・;)
あんまりオブジェクトオブジェクトしたものも好きではなくて。
っというか、物事の隠蔽度合いがイマイチというか、フォーカスしている領域が狭すぎると感じるというか。
SQLを意識しなくて良いからと言って、だらだらとオブジェクトの操作を書いて、それをもってドメインなんちゃらと主張してみたところで、自分はまったく嬉しくありませんが(・∀・;) *3
あげくは、最後の手段として固有のxQLみたいなものを持ち出すのは、脳わいてんのか？、……みたいなのはよくある話(・ω・;)
本当にオブジェクトオブジェクトしたパーシステントフレームワークが有用なのは、人によっては愛憎色々なオブジェクトデータベースを使って、RDBよりオブジェクトデータベースがむいているタイプのシステムを作るときだけだと思うんですけどね。
っで、まあ、論外な話とかは無視するとしても、堕落が始まってしまうのは、その程度の要求で済んでしまうシステムが大多数で、そういう開発に従事している人間が大多数だからだ、……っというのはこれまでのお話(・ω・;)
今時は、そんなつまらない設計が必要な仕事は無くなってきていると思うので、どうでも良いんですけどね、とか、投げやり。
…などと、Twitterのつぶやきから再構成した日記でした(´д｀;)
