[seasar-dotnet:1528] Re: [DBFlute][S2Remoting] リモートオブジェクトを取得したい

西山　はじめ [E-MAIL ADDRESS DELETED]
2009年 11月 27日 (金) 10:29:28 JST 

西山(hajimeni)です。

小谷さん。丁寧にありがとうございます。

Quillとは関係のない話に時間を割いていただき本当にありがとう
ございます。

構成ファイルの分割は、調べてみようと思います。

リフレクションを利用して〜〜は、次のようなイメージでした。

・[ServiceContract]を設定したクラスやインターフェースを、dll
内から探し出す。
・サーバーアプリケーション起動時に、探したクラスを
ServiceHostとしてOpenしていく。（名前は一意になるように）
・（特殊な通信を利用するサービスクラスだけ、設定ファイルを用
意し、そちらを参照して、ServiceHostを作成する）

イメージに一番近いのは、 S2BlazeDSです。

というのも、「通信方法や設定は全て同じものを利用する」という
前提なら、設定ファイルがなくても問題ないなと思った次第です。


クライアントからは、通常通り呼び出しますが、その際はやはり設
定ファイルを利用せず、ファクトリーを利用しようとしています。

具体的には、
public T CreateProxy<T>(){・・・}
というメソッドを用意しています。

この形式にしておけば、

> 「サービスの設計原則：サービスのパターンとアンチパターン」
> http://msdn.microsoft.com/ja-jp/library/ms954638.aspx

このページは知りませんでした。
参考にしたいと思います。

Seasar.NETとは関係のない話になってしまい申し訳ありませんでした。


[2009/11/27 0:28] koyak さんは書きました。：
> 西山(hajimeni)さん
> 
> 小谷です。
> 
> 一日以上考えてみたのですが良い返信を思いつかなかったため
> ノウハウをお持ちな方からのフォローをあてにしつつ
> 書ける範囲で書かせていただきます。
> 
>> サービス数が多いと設定ファイル
>> が膨大になり、管理＋運用後のメンテナンスが大変になるのでは、
>> という懸念点があります。
> 
> あまり解決にはならないかもしれない上に
> サーバ側でないと適用は難しいかもしれませんが、
> 構成ファイルを分割して管理する、などでしょうか。
> 
> 思いっ切り他力本願で恐縮なのですが、
> 「.NET 構成ファイル　分割」といったキーワードで検索すると
> 構成ファイルの分割方法についての情報が手に入るかと思います。
> 
> （私が経験したプロジェクトの場合、画面数からいってもそれほど
> 規模の大きなものではなかったため、
> 設定ファイルも許容範囲なサイズでした）
> 
>> その際、「すべてのサービスを同じ仕組みで提供する」という前提
>> ならば、リフレクションを利用して exe 内のサービスをすべて公
>> 開するという手法は、行ってもいいものなのでしょうか。
> 
> ごめんなさい。
> こちらについてはちょっとイメージがわかないのですが、
> メソッド名＋いくつかのパラメータを引数にもつような
> 汎用的な公開サービスを一つ作って、
> サーバ側でメソッド名からリフレクションで処理を呼び出す、といった感じでしょうか？
> 
> 恥ずかしながら、自分には何とも言えない・・・です。
> 
> 他力本願ばかりで本当に情けないのですが、
> サービス設計についてはMSDNにこんなページがありました。
> 
> 「サービスの設計原則：サービスのパターンとアンチパターン」
> http://msdn.microsoft.com/ja-jp/library/ms954638.aspx
> 
> 直接の役には立たないかもしれませんが、
> 何かの参考にはなる・・・かもしれません。
> 
> お役に立てず、申し訳ないです。
> 
> 2009年11月25日10:54 西山　はじめ <[E-MAIL ADDRESS DELETED]>:
>> 小谷さん
>>
>> 西山(hajimeni)です。
>>
>> 返信遅くなりまして、申し訳ありません。
>> 色々とアドバイスありがとうございます。
>>
>> 内部で検討した結果、次のような形になりそうです。
>>
>> ・[Client.exe] -> [Service.dll] <- [Host.exe]　という構成
>> ・[Client]は、標準のForm＋αで作成する。
>> ・[Service]は、1画面=1インターフェースで作成する。
>> ・[Host]は、[Service]の実装及び、[Service]の公開を行う。
>> ・[Host]は、[DBFlute][Quill]を利用し、[Facade]クラスを用意し
>> て、トランザクションを設定する。
>> ・サービス公開は、[net.tcp]
>> ・すべて同期型で提供する。（どうしてもレスポンスに問題が出た
>> 場合に、非同期型を検討する）
>> ※使えと言われたモジュールは、どうにか回避しました。
>>
>> Serviceは、画面に対応するロジックのような意味で使っていました。
>> しかし、小谷さんの解釈のMicrosoftのサイトにあるような「サー
>> ビス」の意味でとらえて下さって大丈夫です。
>>
>> あと、最後に1点だけお伺いしたい点があります。
>>
>> Seasarとは関係ないのですが、VisualStudioで、サービスやClient
>> のProxyを自動生成できますが、サービス数が多いと設定ファイル
>> が膨大になり、管理＋運用後のメンテナンスが大変になるのでは、
>> という懸念点があります。
>> （今のところ50画面以上になりそうです）
>> （あと、開発者全員に設定ファイルの中身を理解してもらうのも大変）
>>
>> その際、「すべてのサービスを同じ仕組みで提供する」という前提
>> ならば、リフレクションを利用して exe 内のサービスをすべて公
>> 開するという手法は、行ってもいいものなのでしょうか。
>>
>> Web上や書籍のサンプルでは、せいぜい２〜３個程度のサービスし
>> か無い為、その場合のベストプラクティスを模索しているところです。
>>
>>
>> [2009/11/20 23:39] koyak さんは書きました。：
>>> 西山(hajimeni)さん
>>>
>>> 小谷です。
>>>
>>>> イメージでは、次のような感じでよろしいでしょうか？
>>>>
>>>> |Client|          |Server|
>>>> [画面]  ⇒ <WCF> ⇒ [Service] ⇒(*) [Facade] ⇒ [Bhv]
>>>>
>>>> ・(*)の呼び出し部分をトランザクション境界にする。
>>>> ・画面からは、WCFを通してServiceを呼び出す。
>>>>
>>>> 画面:Service = 1:1 のような構成の場合、
>>>> Facade:Service も 1:1 という考え方でよろしいでしょうか？
>>> はい。
>>> （先に確認しておくべきだったかと思いますが、
>>> [Service]はhttp://msdn.microsoft.com/ja-jp/library/ms731067.aspx
>>> にあるような「サービス」の意味で解釈しています。
>>> 間違っていましたらご容赦下さい）
>>>
>>> .NET RemotingでもWCFでも[Service]にあたる部分はASP.NETのPageクラスと同様に
>>> DIコンテナで管理できないため、
>>> (少なくともSeasarの)インターセプターをかけることはできないはずです。
>>> そのため、代わりにFacadeにあたるクラスを用意して
>>> トランザクション（TransactionInterceptor）を設定することになるかと思います。
>>>
>>>
>>> 2009年11月20日10:15 西山　はじめ <[E-MAIL ADDRESS DELETED]>:
>>>> 小谷さん。
>>>>
>>>> 西山(hajimeni)です。
>>>>
>>>> 返信ありがとうございます。
>>>>
>>>>> 個人的にはQuillを使うにせよS2Containerを使うにせよ
>>>>> Seasar.NETを利用するのはサーバ側のみとし、
>>>>> リモートオブジェクトの取得・利用は
>>>>> .NET標準のやり方（公式ガイドなどに載っているような）で
>>>>> 行うことをオススメしたいです。
>>>>> （WCFだけかもしれませんが、
>>>>> VisualStudioで必要なクラスをある程度
>>>>> 自動生成できるはずなので）
>>>> 構成等はまだ、全然決まっておりません。
>>>> 確かに通信部分は.NET標準の方が問題が少なくなりそうですね。
>>>> 検討してみたいと思います。
>>>>
>>>>> ServiceからFacadeの処理を呼び出す、という形が
>>>>> 作りやすいのではないでしょうか。
>>>>>
>>>>> （以前、私が関わったことがある
>>>>> Silverlight(+WCF)+Seasar.NET+DBFluteな
>>>>> プロジェクトでは上記のような形で作成していました）
>>>> イメージでは、次のような感じでよろしいでしょうか？
>>>>
>>>> |Client|          |Server|
>>>> [画面]  ⇒ <WCF> ⇒ [Service] ⇒(*) [Facade] ⇒ [Bhv]
>>>>
>>>> ・(*)の呼び出し部分をトランザクション境界にする。
>>>> ・画面からは、WCFを通してServiceを呼び出す。
>>>>
>>>> 画面:Service = 1:1 のような構成の場合、
>>>> Facade:Service も 1:1 という考え方でよろしいでしょうか？
>>>>
>>>>>> 4.ロジック変更時に、サーバー側のDLLは入れ替え無しとしたい。
>>>>>> というのも、他で開発されたプロジェクトで、
>>>>>> 「SQL文を配列にして投げればトランザクションになる」というラ
>>>>>> イブラリがあり、「これを使うか、同じ仕組みにしてくれ」
>>>>>> という要望があります。
>>>>> こちらについては
>>>>> 恥ずかしながら、私も良さそうな考えが浮かびません。。。
>>>>> このライブラリ（もしくは同等のインターフェース）を
>>>>> 使わざるをえないのであれば
>>>>> Seasar.NETを利用するにしてもコンポーネントの管理と
>>>>> （トランザクションを除く）インターセプターの利用程度に
>>>>> 留めておいた方が無難かと思います。
>>>>> （SQL文そのものではなくSQLファイルのパスを渡すのであれば
>>>>> 工夫すれば外出しSQLと組み合わせることができるかもしれません）
>>>> これは、どうにか利用しない方向で進める予定です。
>>>>
>>>> 周りでは、今だに「SQL文を自力で組み立てて（バインド変数も利
>>>> 用しない）コーディングする手法が根強いため、なかなか手ごわそ
>>>> うでありますが。
>>>>
>>>>
>>>> 大変参考になりました。ありがとうございます。
>>>>
>>>> また、何かご相談させていただくことがある際には、よろしくお願
>>>> いいたします。
>>>>
>>>>
>>>> 以上よろしくお願いいたします。
>>>>
>>>>
>>>> [2009/11/19 23:26] koyak さんは書きました。：
>>>>> 西山(hajimeni)さん
>>>>>
>>>>> 小谷です。
>>>>>
>>>>> 個人的にはQuillを使うにせよS2Containerを使うにせよ
>>>>> Seasar.NETを利用するのはサーバ側のみとし、
>>>>> リモートオブジェクトの取得・利用は
>>>>> .NET標準のやり方（公式ガイドなどに載っているような）で
>>>>> 行うことをオススメしたいです。
>>>>> （WCFだけかもしれませんが、
>>>>> VisualStudioで必要なクラスをある程度
>>>>> 自動生成できるはずなので）
>>>>>
>>>>> リモートオブジェクトの取得でSeasar.NETを利用する
>>>>> ＝クライアント側でもSeasar.NETを利用する
>>>>>
>>>>> ということになると思いますが、
>>>>> 仮にそのようにした場合、Seasar.dllなども一緒に
>>>>> クライアントに配布しなければならなくなります。
>>>>> そうなるとSeasar.NETをバージョンアップさせる必要が
>>>>> 出てきたときなどにコストがかかることになり
>>>>> （クライアントにもよりますが）、
>>>>> .NET Remoting（もしくはWCF）を使う意味が半減してしまうのでは
>>>>> ないかと思います。
>>>>>
>>>>>> 1.C/Sシステムで、.NETを利用。
>>>>>> 2.DBとの接続は、サーバーが行う。
>>>>>> 3.トランザクション処理を行いたい。
>>>>>> [Form] ⇒A⇒ [Service] ⇒B⇒ [Bhv]
>>>>> という構成であれば、西山さんがおっしゃる通り
>>>>> Aの部分から右をDLLとしてサーバーに配置
>>>>> ↓
>>>>> DBFlute.NETを利用したDBアクセス処理を実装
>>>>> ↓
>>>>> Facadeのようなものを用意してそれをトランザクション境界に
>>>>> ↓
>>>>> ServiceからFacadeの処理を呼び出す、という形が
>>>>> 作りやすいのではないでしょうか。
>>>>>
>>>>> （以前、私が関わったことがある
>>>>> Silverlight(+WCF)+Seasar.NET+DBFluteな
>>>>> プロジェクトでは上記のような形で作成していました）
>>>>>
>>>>>> 4.ロジック変更時に、サーバー側のDLLは入れ替え無しとしたい。
>>>>>> というのも、他で開発されたプロジェクトで、
>>>>>> 「SQL文を配列にして投げればトランザクションになる」というラ
>>>>>> イブラリがあり、「これを使うか、同じ仕組みにしてくれ」
>>>>>> という要望があります。
>>>>> こちらについては
>>>>> 恥ずかしながら、私も良さそうな考えが浮かびません。。。
>>>>>
>>>>> このライブラリ（もしくは同等のインターフェース）を
>>>>> 使わざるをえないのであれば
>>>>> Seasar.NETを利用するにしてもコンポーネントの管理と
>>>>> （トランザクションを除く）インターセプターの利用程度に
>>>>> 留めておいた方が無難かと思います。
>>>>> （SQL文そのものではなくSQLファイルのパスを渡すのであれば
>>>>> 工夫すれば外出しSQLと組み合わせることができるかもしれません）
>>>>>
>>>>>
>>>>> ご相談になられていることと論点がずれてしまって
>>>>> いましたらご容赦下さい。
>>>>>
>>>>>
>>>>> 2009年11月19日20:32 西山　はじめ <[E-MAIL ADDRESS DELETED]>:
>>>>>> お世話になっております。
>>>>>> 西山(hajimeni)です。
>>>>>>
>>>>>> .NET Remoting や WCFを通したリモートのオブジェクトを取得した
>>>>>> い場合、 Seasar.NET の機能を利用してどのように取得すればよろ
>>>>>> しいでしょうか？
>>>>>>
>>>>>> 想定している利用環境は次のとおりです。
>>>>>>  DBFlute.NET 0.8.9.5
>>>>>>  Seasar.NET 1.3.17
>>>>>>
>>>>>> S2Remoting.NET のページはあるようなのですが、使い方等がいま
>>>>>> いちわかりません。
>>>>>>
>>>>>> 具体的に実行したいことは次のようなことです。
>>>>>>
>>>>>> 1.C/Sシステムで、.NETを利用。
>>>>>> 2.DBとの接続は、サーバーが行う。
>>>>>> 3.トランザクション処理を行いたい。
>>>>>>
>>>>>> [Form] ⇒A⇒ [Service] ⇒B⇒ [Bhv]
>>>>>>
>>>>>> という構成の場合、Aの部分から右をDLLとしてサーバーに配置し
>>>>>> て、Form側からリモートオブジェクトを取得すればよいのかなと
>>>>>> 思っております。
>>>>>>
>>>>>> しかし、
>>>>>> 4.ロジック変更時に、サーバー側のDLLは入れ替え無しとしたい。
>>>>>>
>>>>>> といった場合は、どのように実現させれば良いのかは見当が付きま
>>>>>> せん。
>>>>>>
>>>>>> というのも、他で開発されたプロジェクトで、
>>>>>> 「SQL文を配列にして投げればトランザクションになる」というラ
>>>>>> イブラリがあり、「これを使うか、同じ仕組みにしてくれ」
>>>>>> という要望があります。
>>>>>>
>>>>>> 以前のプロジェクトで、 Seasar.NET ＋ DBFlute.NET を利用した
>>>>>> 時に、非常に生産性がよかったので、出来れば同じように開発した
>>>>>> いと思っております。
>>>>>>
>>>>>> しかし、4はほぼ無理だと思っております。
>>>>>>
>>>>>> よって、Aの部分でオブジェクトをリモートから取得したいと思っ
>>>>>> ております。
>>>>>>
>>>>>>
>>>>>> .NET について詳しく理解しているわけではありませんので見当違
>>>>>> いのことを言っているかもしれませんが、お知恵をお借りしたいと
>>>>>> 思っております。
>>>>>>
>>>>>> 以上よろしくお願いいたします。
>>>>>>
>>>>>> --
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> 西山　はじめ
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>> --
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 西山　創
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> --
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 西山　はじめ
>> ++++++++++++++++++++++++++++++++++
>>
>> _______________________________________________
>> 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
> 
> 


-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
株式会社フジミック　
　　　　　　　　システム開発センター　ソフトウェア開発部
　西山　創
[E-mail]：[E-MAIL ADDRESS DELETED]
　
〒140-0002　東京都品川区東品川3-32-42　フジテレビ別館7階
[TEL]：03-5495-1060
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

seasar-dotnet メーリングリストの案内