[seasar-dotnet:1615] Re: 自動バインディング対象について

2010年 3月 19日 (金) 10:33:37 JST

久保(jflute)です。

> S2Daoが使える主流のコンテナはS2Container.NETだと思い込んでいたのですが、
> どうもそうではないみたいですね。。^^;
そうですね。今やQuillとの組み合わせの方が主流とも言えます。
(コミッタ間で聞く話レベルでの動作実績ということでも)

> 現在考えている構成でQuillに置き換えた場合、各開発者がImplementation属性とS2Dao属性を設定しなければならず、それらの付け忘れに不安がありますが、
> 30人規模のPJでも問題にならなかったということで、なんとかなるんじゃないかと思ってきました。
Implementation属性とS2Dao属性に関しては、万が一
つけ忘れても、要は全く動かないので、特に問題には
ならないのかもしれません。
Transaction属性は、全てのFacade(or Service or Logic?)を
リフレクションで属性の有無をアサートするテストを一つ書いて
しまえば、かなり安心感出ると思います。

> また、S2Container.NETはコンテナの起動時間が遅く、開発時にうっとおしく感じるだろうと予想してたのですが、
> Quillではそれも解決しそうです。
(自動)単体テストの時間は、ぐぐっと短くなりました。

> ということで、Quillを再検討してみたいと思います。
> 同時にDBFlute.NETも検討してみたいと思います。
ありがとうございます！
DBFlute.NETを使えば、少なくともDB側のコンポーネントで
属性の付け忘れっていう心配は無用になります。
DaoもBehavior(Daoの代理オブジェクト)も全て自動生成なので。
何かわからないことがあったら気軽に聞いてくださいね。

2010/3/19 Tatsuharu Kawakami <[E-MAIL ADDRESS DELETED]>:
> 川上です。
>
> 久保さん、返信ありがとうございます。
> とても参考になりました。
>
> S2Daoが使える主流のコンテナはS2Container.NETだと思い込んでいたのですが、
> どうもそうではないみたいですね。。^^;
>
> 現在考えている構成でQuillに置き換えた場合、各開発者がImplementation属性とS2Dao属性を設定しなければならず、それらの付け忘れに不安がありますが、
> 30人規模のPJでも問題にならなかったということで、なんとかなるんじゃないかと思ってきました。
>
> また、S2Container.NETはコンテナの起動時間が遅く、開発時にうっとおしく感じるだろうと予想してたのですが、
> Quillではそれも解決しそうです。
>
> ということで、Quillを再検討してみたいと思います。
> 同時にDBFlute.NETも検討してみたいと思います。
>
> 今後も不明点等でてくると思うので、その際はよろしくお願いします。
> ありがとうございました。
>
>
> 2010年3月18日20:46 kubo <[E-MAIL ADDRESS DELETED]>:
>> 久保(jflute)です。
>>
>> 川上さん、こんばんは
>> (そして、吉田さんフォローありがとうございます)
>>
>> 自分がコメントできるものだけという感じで。
>>
>>> S2Container.NETで自動バインディングの対象となるのはInterfaceのTypeのみとなっていますが、
>>> これはどういった理由からなのか教えていただけないでしょうか？
>> 正式な理由、ということになると移植作業時に関わってないので、
>> なんとも言えませんが、Javaから移植したタイミングの状態のまま
>> であると想像しています。JavaもI/Fなしは2.4からということで、
>> 移植は明らかにそれより前なので。
>> そして、今の(Seasar.NETの人的)リソースと、運用ポリシーから
>> S2Container.NETは安定重視であまり大きな修正を入れないよう
>> にしているので、その辺を修正する予定も今のところありません。
>>
>>> 開発規模が大きくなったり開発メンバーのスキルが高くなかったりするとき、
>>> 一例としては「属性のつけ忘れでトランザクションがかけられていない」
>>> といったことが考えられるので、一括で設定が可能なS2Container.NETを採用しました。
>>> Quillでもそのような機能があるのであれば教えていただきたいです。
>> Quillでは、その機能はないと思います(ドキュメントにも無いし)。
>> 設定ファイルレス、ソースに書いてない処理が(極力)勝手に付与される
>> ことはあまりないように、というのがポリシーなので、
>> 別の設定ファイルに規約を定義してAOPが付与されるという
>> 機能は少なくともQuillのメインとするところではないと思われます。
>>
>> 個人的には、そのポリシーを引き継ぎつつ、より安全にするなら、
>> 画面仕様書(or 定義書)のようなものから、
>> Facadeクラス(サービスとかロジックとか色々な言われ方しますが)
>> を自動生成するのが良いと思っています。
>> (全く同じ構成ではないですが実際にやってるところ幾つも経験してます)
>> 大規模ならなおさら仕様書なしで先に実装を進めることは考えづらいので。
>> また、もっと簡易なやり方で、自動単体テストでそのFacadeクラスに
>> トランザクション属性が付いてるかどうかのチェックを一個書けば、
>> それだけでも十分とは思います。(構成とかにも寄りますが)
>>
>> ただ、実際にQuillを大規模(プログラマ30人くらい!?)で
>> 利用されているプロジェクトで、特にそういった対応しなくても問題
>> にはならなかったと聞きました。
>> 「こういった規約のメソッド作ってね」ってのと「トランザクション属性を
>> 付けてね」ってのとは(リスクと手間は)そんなに変わらないのかもしれません。
>> (クラスにトランザクション属性付けるなら、なおさら差はないかも)
>>
>> #
>> # さらに個人的には...普段Javaの方でやってるので、
>> # 「Pageクラスであるメソッドで始まるものはトランザクション」
>> # っての(やはり慣れてるので)便利だなぁとは思っていますが...
>> #
>>
>> ただ、まだまだ(Quillとして)議論余地のある問題かもしれません。
>>
>>>> ですので、自分の中では
>>>> Seasar 2.3(Java) = Seasar.NET
>>>> Seasar 2.4(Java) = Quill
>>>> みたいな意識でいます。
>> 補足させていただきますと：
>>
>> S2Container.NETは、ベースは(確か)2.2で、
>> 重要な機能(自動登録)だけ後から付けたした感じのはずです。
>> おおよそ、2.3という認識で間違いはないと思いますが、
>> 細かいところではそうでもない部分も多々あるかと思います。
>>
>> そして、Quillは2.4の立ち位置というより、2.4は踏襲せずに
>> 独自の路線になっているという感じです。
>> どちらかというと、Google Guiceに近いかなと。
>> (完全に同じではないですが)
>> また、こちらの記事が参考になります。
>> http://d.hatena.ne.jp/jflute/20081215/1229321164
>>
>> #
>> # 「I/F無いといけない問題」は、自分も最初からうっとおしくて、
>> # (R#が無いとソース追う時にすごい大変だしVisualStudio)
>> # 大昔のDBFlute.NETでは、仕方なくBehaviorもI/Fがあった
>> # のですが、完全にQuillに移行してI/Fなしで実現しています。
>> # 個人的には、最初から再利用想定レイヤとかであればあった方が
>> # いいと思っていますが(I/F先に作って別のシステムに提供するとか
>> # マネジメント的にも都合が良いし)、そうでないような場合、
>> # 「あなた(画面)専用のレイヤだよ」って言いきれてしまうような
>> # システムであれば手間のかかるI/Fは不要かなと。
>> # (IDEでもっと楽に作れるようなサポートがあればいいですけどね)
>> #
>>
>> 2010/3/17 Tatsuharu Kawakami <[E-MAIL ADDRESS DELETED]>:
>>> 川上です。
>>>
>>> 吉田さん、返信ありがとうございます。
>>>
>>> 自分も昔はIFは切り分けるべき！という考えでしたが、
>>> SAStrutsが出たあたりからだいぶ考えが変わってきました^^;
>>>
>>>
>>> Quillも検討したのですが、コンポーネントとアスペクトの自動登録機能がなかったため不採用としました・・
>>>
>>> 開発規模が大きくなったり開発メンバーのスキルが高くなかったりするとき、
>>> 一例としては「属性のつけ忘れでトランザクションがかけられていない」
>>> といったことが考えられるので、一括で設定が可能なS2Container.NETを採用しました。
>>> Quillでもそのような機能があるのであれば教えていただきたいです。
>>>
>>>
>>>
>>>
>>> 2010年3月17日11:00 Takafumi Yoshida <[E-MAIL ADDRESS DELETED]>:
>>>> いつもお世話になります。吉田@オプティクスです。
>>>>
>>>> 2010年3月17日10:18 Tatsuharu Kawakami <[E-MAIL ADDRESS DELETED]>:
>>>>> S2Container.NETで自動バインディングの対象となるのはInterfaceのTypeのみとなっていますが、
>>>>> これはどういった理由からなのか教えていただけないでしょうか？
>>>>> http://s2container.net.seasar.org/ja/dicontainer-reference.html#AutoBindingMode
>>>>
>>>> 自分もよくは知らないのですが・・・
>>>>
>>>> そもそもDIの考え方のスタートとして、コンポーネント間の関係をインターフェースで定義しておいて
>>>> 具体的なコンポーネント（実装）は別に実装し、その関係を設定ファイルにもたせることで
>>>> コンポーネント間の依存関係をコードから排除するって考えがあったように思います。
>>>>
>>>> このことから、インターフェースと実装は分けて書くべし！的な風潮があったのかも。
>>>> これをベースにしたのがJava版のSeasar2.3系列であり、.NET版Seasarだと思われます。
>>>>
>>>> ただ、この風潮ってあまりメリットがなくなってきて、実装だけでもいいのでは？となって
>>>> Java版のSeasarの2.4系列ではインターフェースなしでもコンポーネントを作成できるようになり
>>>> .NETではQuillが生まれた、というふうに自分は理解してます。
>>>>
>>>> ですので、自分の中では
>>>> Seasar 2.3(Java) = Seasar.NET
>>>> Seasar 2.4(Java) = Quill
>>>> みたいな意識でいます。
>>>>
>>>> #あ～、自分もよく理解できてないな・・・ツッコミ希望w
>>>>
>>>>> IFを作成する作業が面倒なので、
>>>>> 重大な理由が無ければ実装クラスでも自動バインディングするようにカスタマイズしたいと考えております。
>>>>
>>>> 上記の様なニーズであれば、Quillを使ったほうがいいかもしれません。
>>>> Quillであれば、インターフェースなしでImplementationアノテーションをクラスに記述すれば、Quillでコンポーネント
>>>> として扱えます。
>>>> _______________________________________________
>>>> seasar-dotnet mailing list
>>>> [E-MAIL ADDRESS DELETED]
>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>
>>>
>>>
>>>
>>> --
>>> --------------------------------------
>>> Tatsuharu Kawakami
>>> [E-MAIL ADDRESS DELETED]
>>> _______________________________________________
>>> seasar-dotnet mailing list
>>> [E-MAIL ADDRESS DELETED]
>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>
>> _______________________________________________
>> seasar-dotnet mailing list
>> [E-MAIL ADDRESS DELETED]
>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>
>
>
>
> --
> --------------------------------------
> Tatsuharu Kawakami
> [E-MAIL ADDRESS DELETED]
> _______________________________________________
> seasar-dotnet mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>