[Seasar-user:396] Re: AOP-DAO
B gluegent.com Masataka Kurihara
kurihara
2004年 3月 3日 (水) 11:09:56 JST
栗原です。
> 前の例では、DAO層しか書かなかったので、分かりづらかったかも。
> Core Concernに永続化を置いているわけではないです。
了解です。ここは同じ像が見えてました。誤解はしてなかったと
思います。
> メソッドの引数にAspectを仕掛けて置き換えるのは、
> ちょっとトリッキーな感じがします。
> サービスがDAOへの参照を持って呼び出すほうが自然な気が(^^;
ここも、同感。Aspectが引数いじるのって(または、Component
が引数いじられるのを期待してとは)、結局AspectがCore Concern
に関わっていて、かつ登場人物間が疎結合でなくなってきちゃうの
でAOPなアプローチをしている意味が薄れてしまうと思ってます。
ただ、どっかで見たのですが、こういう機能を提供しているものも
見ました。まったく別技術である、ServletFilterでHTTPリクエスト
のエンコード変換したりとかする手法よりの連想で思いついたので
すが、賛否あると思います。実は私も否だったりします。
> 私の考えでは、モデル(MVCのモデル)をサービス、DAO、Entityにわけ、
> クライアントは、サービスとだけお話し、Entityをやり取りする。
> サービスは、DAOへの参照を持ち、永続化ロジックはDAOに依頼し、
> 業務ロジックは自分で処理する。
さらに、同感。私もこれまでそう考えてきました。また、Seasar
出会う以前の一ヶ月ぐらい触ってた限りでは、SpringFrameworkもこ
う考えているようで、DAO-ORMにはメインには既存ORMツールをおい
て考えていると、作りやドキュメントより感じられます。
しか〜し、別スレッドのひがさんのマイルストーンにあった、
> DAO:データの永続処理をAOPで提供。もとのSqlet
というので「なに!IoCコンテナ使うというだけでなくAOP?」と思い、
> <aspect>
> <component class="org.seasar.framework.dao.advices.DaoAdvice">
> <!-- DataSourceコンポーネントの名前。他で定義済み -->
> <arg>jdbc/default</arg>
> <!-- XMLのリソースパス -->
> <arg>'hoge/dao/EmployeeDao.xml'</arg>
> </component>
> </aspect>
うぉ、ほんとにAdviceで(狭い意味のAOPで)実装するのか〜と。Advice
で実装するからには、aspectタグの設定およびAroundAdviceを実装しなけれ
ばならないのでしょうが、DaoAdvice で実装する内容が Advice である必要
性が見つからないのです。POJO・Type2&3 IoCコンテナですから、作法は無
いに越したことはないわけで、IoCコンテナで使われるというだけの縛りで
POJO‐DAO-ORMなコンポーネントとして、独立に新Sqletワールドが広がった
ほうがシンプルで、たとえばSpringFrameworkなどの中ででもSqletが使える。
さて、ここからAOP-DAOでなく、ひがさんに振ってもらったXMLのほうの話。
> aspectタグについては、通常だと<aspect>アドバイス名</aspect>
> だけですみます。アドバイスを直接埋め込む場合は、
> argタグやpropertyタグと同じように子タグにcomponentタグを
> 使ったほうが統一がとれてて良いかなと思ってます。
なるほど、OK。統一は学習効果上も大事だと思います。日記の記事を見
ましたが、Pointcutを指定する場合は、以下の感じですか?
<aspect>
<component class="Foo.BarAdvice">
<arg>Boo</arg>
<arg>checkera</arg>
</component>
<pointcut method="calcSalary"/>
</aspect>
> と書いていて、まだ、XMLでの設定機能はリリースしてないことを
> 思い出しました。
はやくっ、はやく(^^)/
--
株式会社グルージェント
栗原 傑享(くりはら まさたか)
渋谷区渋谷3-7-6 第6矢木ビル4F
TEL:03-5469-8869 FAX:03-5469-8879
URL:http://www.gluegent.com/
--
Seasar-user メーリングリストの案内