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

2010年 3月 18日 (木) 20:46:08 JST

久保(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
>