PerlのCatalystとJavaのStrutsのMVC実装の比較をしてみます。
Struts
Model:
Struts
図ではModelとしてActionFormとなっていますが、ActionFormはむしろViewに近い存在です。Strutsにおける実際の開発ではむしろJavaBeansをModelとして扱い、ModelのSerializeにはHibernateのようなO-Rマッピングツールなどを使います。SerializeにはDAOパターンを使うことが多いです。
Catalyst
Catalystでは純粋なModelもフレームワークに組み込まれています。Class::DBIなどのActionRecord的アプローチを取るためModelそのものにSerializeの機能を含めることが多いためDAOなどを使う場面は少ないです。
Contoller:
Struts
StrutsではActionServletクラスがstruts-config.xmlに従って指定されたActionクラスにディスパッチします。Actionクラスにはビジネスロジックを実装してその結果によってActionServletがstruts-config.xmlに従ってViewを返します。
Ctalyst
CatalystではControllerとURLが密接に関係しているためディスパッチはURLによって判断されます。Controllerにビジネスロジックを実装して結果としてViewを返します。
View:
Struts
StrutsではJSPなどを用います。
Catalyst
CatalystではTemplate-Toolkitなどを用います。
CatalystとStrutsの相違点は、Strutsではstruts-config.xmlという設定ファイルによってアプリケーションの挙動の多くをを決定する必要があるため、このファイルの管理が煩雑になりがちです。CatalystではURLとControllerが密結合している(ある意味で制限ではあるのですが)ため、必要な設定ファイルは存在しません。
Model部分の実装ではCatalystではActiveRecord的アプローチを取るのに対して、StrutsではHibernateなどのO-Rマッピングツールが使われることが多いのも違います。これは、開発規模や経緯などで優位性が違ってくると思うのですが、データベースと密接な関係が許されたり、新規のプロジェクトで新たにデータベースの設計が行えるのであればActiveRecord、他のアプリケーションからの利用があったり、既存のスキーマを使う必要があるのであればHibernateのアプローチが向いていると思います。(この辺はTheServerSide.COMの記事が詳しいです。)
一方、類似点は「薄いフレームワーク」であるという点です。Rails on Rubyなどよりも規制が少ない分応用が利き汎用性が高い反面、よく言われるように色々できてしまう分、チーム開発などの場面では自分で規制を決める必要があります。
コメントする