読者です 読者をやめる 読者になる 読者になる

log

日記です

ほげほげ

ほげほげ

えむぶいしー

なんかえせMVCっていう言葉を聞いてなんかちょっと考えた

とおまけで

  • ユーティリティークラスとか
  • Constants、定数だけ書くクラスとか
  • Enumとか
  • Entity
  • Bean
  • DTO
  • うわー

言い方がありすぎてカオス。

ほげほげ

コントローラー層はrequestを受けて、値をBeanにつめたりviewに値渡したり(push型っていうのかな?)、渡せる状態(pull型っていうのかな?)にしたり、sessionにhogeったりするやつ?
プレゼンテーション層は、コントローラーから値をとったり、受け取って使える状態にしたりする奴?後viewってる感じのやつ?
ビジネスロジック層はThe・ロジック。データの永続化はここでは見ないでDAO層にやらす。でもトランザクション管理はここで持つ。のでビジネスロジック層とDAO層は結構密結合になりやすい?基本Webなら1リクエスト1トランザクション、1リクエスト1スレッド、で"一つのスレッドでトランザクションを管理する"やり方がやりやすいのかなー?
クラスまたいじゃう、でも疎結合にしたい、そうだThreadLocal使って1スレッドの共有ゾーン使おう、でそれをラッパーしてTransactionUtil的なの作ろう、的な。ここにDBのセッションとトランザクションを置いて、ビジネスロジック層とDAO層で共有化。
基本ビジネスロジック層の頭でトランザクション開始して、ケツで終了すればおk。DAOの中や、ビジネスロジックの途中でエラーになったらrollbackで。
って感じの整理じゃないっすかね、Javaなら。
で良い感じのフレームワーク使えば、上記で期待している動きをアノテーションつけるだけでやってくれたりするんじゃないっすかね。@transactionとか?

それはMVCと言うよりはJ2EEパターンなのかなぁ〜と思っていたけど、単純にMVCとも呼ぶのかな?
うぬぬMVCだと、コントローラー、ビジネスロジック、DAOが結構ごっちゃになる、っていうのが注意しようという点なのかな。
ロジックを書くのはビジネスロジック(サービス)層だし、データの永続化処理はDAOだぞ、と。コントローラーはRestful URL作るのと値を受け取り、ビジネスロジックに渡すだけだぞ、と。データのそのまま渡してはいけなくて、疎結合にするためにビジネスロジック⇔DAOの間のデータはコントローラーからきたデータをそのまま渡すような仕組みではいけないようで。そこのインターフェースは少し観点を変えて考えるべきなのかな。

ネム。