<< 実践 ソフトウェア・アーキテクチャ : レイヤ構造と import 文 | main | 実践 ソフトウェア・アーキテクチャ : Spring DAO + iBatis >>

実践 ソフトウェア・アーキテクチャ : Spring MVC

Web アプリケーションのアーキテクチャの勉強には、Spring MVC が参考になると思う。

どのフレームワークも良い点も悪い点もあるので、フレームワークの優劣は簡単に決まりません。
でも、MVC パターンによる関心の分離という視点で見れば、 Spring MVC は、他のフレームワークよりよくできていると思う。

Spring フレームワークは、ドメイン層のオブジェクト、つまりドメインモデルを実装した POJO を他の層で活用するという考え方です。

ドメインモデルは自分で設計・実装してね。それ以外のレイヤは、私たち Spring コミュニティ が設計・実装の best practice を提供します、という思想のフレームワークですからね。

その思想の一部として提供されている、Web アプリケーション API が Spring MVC です。 ( Servlet をさらに抽象化して、 best practice を実装したもの、だそうです)

Model

Spring MVC は M つまり Model は、ドメイン層の POJO をそのまま使うことを想定している。トランスファーオブジェクト (DTO) に変換する発想はないです。

View

さまざまな View テクノロジーを選択可能です。私たちは、テンプレート方式の Velocity を使っています。 View テクノロジーが選択可能になっている、ということは、 View についての関心をうまく分離して、インターフェース定義ができている。そのインタフェースを使って、JSP, JSF, Velocity などを View の実装技術として選択できるということです。 ここらへんの設計思想と実装の具体例は、アーキテクチャ、ソフトウェアの基本設計の参考になります。

Controller

Controller は、なんでもここにかけてしまう場所ではあります。 ドメイン層の POJO が単なるデータの入れ物にしてしまうと、ここに大量の手続きをコーディングすることになる。

ドメイン層のオブジェクトが豊かな振る舞い(メソッド群)を持っていても、アプリケーションロジック(サービス手順)にあたるよロジックは、ここにかけてしまう。

私たちは、これは問題だと思っているので、 このコントロールの部分を抽象化した Spring Web Flow を使っています。 Spring Web Flow を使うと、アプリケーションサービスは、アプリケーション層のオブジェクト( POJO ) として分離して記述してするスタイルが自然にできるようになります。

Spring Web Flow は、XML 定義だけなので、そもそも、ごりごりロジックは書けない。だから、必然的にアプリケーションロジックは、POJO bean として設計・実装することになる。

書こうとしてもごりごり書けないというの、ソフトウェア・アーキテクチャの実装方式として良いことだと思います。

たとえば、Java Servlet を直接コーディングすればなんでもごりごり書けてしまう。 JSP もそうですよね。 自由にできることを規約やセンスでしばってみても、なかなかうまくいきませんから。

Spring Web Flow 2.0 は、1.0 に比べ、かなり簡潔に記述できるようになりました。 MVC のコントロール層の記述として、理解しやすく、変更が容易になったと思います。

コメント
3.0 になって、さらに進化。
アノテーションを使って、シンプルに、記述できるようになった。
RESTスタイルの実装をかなり意識した仕様になっている。
  • masuda220
  • 2011/02/16 12:22 PM
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM