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 のコントロール層の記述として、理解しやすく、変更が容易になったと思います。
どのフレームワークも良い点も悪い点もあるので、フレームワークの優劣は簡単に決まりません。
でも、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 のコントロール層の記述として、理解しやすく、変更が容易になったと思います。