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

koyak [E-MAIL ADDRESS DELETED]
2009年 11月 27日 (金) 00:28:13 JST


西山(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上や書籍のサンプルでは、せいぜい2〜3個程度のサービスし
> か無い為、その場合のベストプラクティスを模索しているところです。
>
>
> [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 メーリングリストの案内