- - PR -
Windowsアプリケーションのロジック分離
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-07-05 14:08
皆様こんにちは。
現在.NET環境で、アプリケーションを開発しようと考えています。 基本的に、クライアントはWindowsアプリケーションですが アプリケーションサーバを別途配置し、ビジネスロジックはサーバに置く 多層構造での設計を考えています。 この場合、Windowsクライアントとサーバ間のデータやり取りは どのような方式を取るのがベストなんでしょうか？ 選択肢としては ・.NETリモーティング（TCP or HTTP） ・Webサービス ・xml形式でデータを返す（？） などを考えています。 考慮したい事項は以下の通りです。 １．将来Flex,CurlなどWindowsアプリケーションでははないクライアントが現れること考慮する。（その場合もなるべく手を加えないでサーバロジックを再利用したい。） ２．エラーハンドリング（エラー情報をどこまで詳細に取得できるのか？） ３．パフォーマンス ４．開発効率 .NET初心者の若輩者ですが、 メリット、デメリットなど有識者の方々のお知恵をお貸し下さい。 | ||||
|
投稿日時: 2005-07-05 14:49
こんにちは。
XML形式でデータをやりとりするXMLWebサービスでどうでしょうか。 僕自身も大してアドバイスも出来ませんが、クライアント側でデータを加工しやすいのは DataSetで値を返すやり方がベストなのですが、クライアントが将来Windows以外になるなら XML形式でデータを返す方法が良いと思います。 ドットネットマガジンの以前の号で特集やってましたよ！ [ メッセージ編集済み 編集者: とっと 編集日時 2005-07-05 14:50 ] | ||||
|
投稿日時: 2005-07-05 15:03
(XML)WebサービスをASP.net(C#)で開発した経験から。
[ Webサービスの個人的評価 ] １．Windowsアプリ・Webアプリ・コンソールからも呼び出し可能。 技術自体はOS等にも非依存らしい。（利用したこと無いので良く知らない） ２．Webサービス側で例外が発生し、処理されない場合、クライアント側にも伝播される。 例外を処理して、エラーの戻り値を返すことも出来る。 ３．超高速とはいえない。大量のデータ通信を伴わない限り問題無いレベル Webサービスの特性を捉えた設計になっていれば、大丈夫でしょう。 ４．開発〜デバッグの生産性は、非常に高い。 保守性は、設計次第ですが、決して低くは無いでしょう。 簡単に言うと、開発イメージはこんな↓感じです。 [Webサービス側] プロジェクトを作成して、適当な関数にWebMethod宣言を追加したら完成。 [クライアント側] Webサービスに対してWeb参照を追加したら、公開されたクラスやメソッドが使用できる。 個人的にはお勧めなんですけど、 他の技術を知らないため比較は出来ません。 
| ||||
|
投稿日時: 2005-07-05 16:32
とっとさん、葉瀬崎さん
ご回答ありがとうございます。 Webサービスでサーバ側を実装するのが良さそうと思えてきました。 インターフェイスを明確化した設計を行えば、保守性も向上しそうですし。 もちろんクライアントには依存しないですしね。 ただパフォーマンスの点で.NETリモーティングも気になっています。 Webサービスとの比較なんかの情報ってどこかに無いものでしょうか... | ||||
|
投稿日時: 2005-07-05 16:33
考慮する事項のうち、どういった部分を優先的に考えるかで実装も変わってくるかな。 1が絶対的な優先事項なら、Webサービスを使うのがよさそうです。 その際、DataSetなどの.NET特有のクラスは便利であっても使っちゃいけません。 エラーハンドリングもWebサービスで返せるように自分で実装ですね。 で、パフォーマンスはWebサービスの特性からそれほどよいとは言えないかな。 開発効率は上記のとおり自分で考えて実装しないといけないことが多いので あまりよくならないでしょう。 パフォーマンスが優先ならリモーティングかな。 でもリモーティングだとクライアント側が.NET限定になりますね。 開発効率を優先するなら、.NETでがちがちに固める。 ただし、ASP.NETを使うならともかく、それ以外のWeb系のクライアント？を 利用するには苦労するんじゃないかと思います。 | ||||
|
投稿日時: 2005-07-05 16:53
自分も１年前にどちらを選択するべきなのか悩んだ時期があって、いろいろ検証していました。
その時の結果資料は紛失！？してしまったので、覚えている程度で特徴を纏めてみました。（間違っていたらゴメンなさい。。。） ========================================================================= .NETリモーティングの特徴 通信方法として、標準でTCP、HTTPがサポートされている。 データフォーマットとして、標準でSOAP、バイナリがサポートされる。 HTTPによる通信をサポートしたため、従来のDCOMの問題であった「専用プロトコルであるためにファイアーウォールを越えられない」問題を解消している 双方が.NET環境であることが必要。 バイナリ転送が可能なため、高速化が期待できる（でも噂では大して早くならないらしい←実測してみる必要あり）。 XML Webサービスの特徴 特定企業に依存しない業界標準インターフェースであるため、他システム（異なるOS、異なる環境）での利用が可能 ファイヤーウォールを越えることができる 多様な環境とシームレスな接続が可能 処理が冗長化し、性能がトレードオフされる ひとつのサブシステム内での利用価値は低く、企業をまたがるサブシステム間での利用価値の高いテクノロジー 一度公開すると、IFを変更するのが難しい。（そのサービスを利用するすべてのクライアントが影響を受けるため ========================================================================= あとデータ抽出のサンプルも作成し、パフォーマンスの違いも見ましたが、 どっとねっとふぁんさんのおっしゃるとおり、リモーティングの方が優れていました。 | ||||
|
投稿日時: 2005-07-05 17:27
前に似たような構成のアプリケーションを開発していました。.NET Remotingより理解しやすく楽に開発できると思い（それは安易な間違いでした）、ビジネスロジック層にXML Webサービスを採用しました。
モンモンさんのビジネスロジックがどのような物か分かりませんが、Webサービスはその性質上、自身のオブジェクトの状態を保持しておけないので私は外部リソース（DB、ファイル、etc...）に保存したり、WebサービスからWindowsサービスを呼んで、実際のビジネスロジックはWindowsサービスにホストさせる、など色々試行錯誤しました。 またインタフェース層に状態を持つとUIが肥大し、BOがスカスカになってしまうような主体性のないビジネスロジックになってしまったケースもありました。 更に実行時間が掛かる重い処理や非同期処理にも向いていない為、非常に苦労しました。.NET Remotingだと、この辺りは割と苦労しないと思います。 何を採用するかにはビジネスロジックの性質も考慮すると尚良いと思います。クライアントをWindowsだけと考えれるなら個人的にはWebサービスと.NET Remotingを使い分けるのが良いと考えています。 | ||||
|
投稿日時: 2005-07-06 11:54
どっとねっとふぁんさん、かえでさん、ryuujiさん
ご回答ありがとうございました。 ビジネスロジックも含め、まだ未確定なことが多くて悩ましい状態です。 ただ、クライアントの種類が増えていくことを考えると Webサービスしか無いように考えていましたが、 皆様のご回答で、「まだハッキリした要件が出ていないのに それに振り回されるのは良くない。」という考えに至りました。 ですので、リモーティングで開発を進め、後から他のクライアントに 公開する要件が出た時点で、必要な個所のみWebサービスの開発を行おうと思います。 ビジネスロジックの内容によるかと思いますが、.NETを採用しているのですから、 後からリモーティングを簡単にWebサービス化できるはず（ですよね？）。 皆様、丁寧にご回答を頂きありがとうございました。 様々な選択肢があるということは、それを選ぶ側にも、 相応の知識が要求されるのですね。 とても勉強になりました。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。