C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[1]: ビジネスロジックをWebサービス化することのメリット、デメリ

(過去ログ 79 を表示中)

[トピック内 26 記事 (1 - 20 表示)]　 << 0 | 1 >>

■46615 / inTopicNo.1)

　ビジネスロジックをWebサービス化することのメリット、デメリ

▼■

□投稿者/ season (1回)-(2010/02/06(Sat) 22:32:11)

分類:[.NET 全般]　

こんばんは。

業務アプリケーションの開発を検討しています。
作った業務アプリケーションは、パッケージシステム化して様々な顧客に販売することも考えています。
言語はC#3.0でWindows Formアプリケーションにする予定です。
ちなみにOSはWindows XP SP3です。

そこでビジネスロジックをWindows Formアプリケーションに含めてしまうか
Webサービスにするかを悩んでおります。

サーバーはWindows Server 2003を用意することになっていまして、
Webサービスを利用するのであれば、こちらもC#3.0で実装する予定です。

この場合、Webサービスを利用するとどういうメリット、デメリットがあるでしょうか？
もしよろしければ、教えて頂けませんか？

私なりに考えてみましたので、間違っていましたら、
教えてください。

＜メリット＞
・UIとビジネスロジックを分離できる。
・クライアントのOSがWindows以外になっても、
　ビジネスロジックは修正しなくて良い。
・ビジネスロジックを修正しても、配布が容易。
・Webシステム化をする際に、UI部分だけを変更すれば良い。

＜デメリット＞
・Webサーバーがないと動かない。

よろしくお願い致します。

引用返信 編集キー/

■46617 / inTopicNo.2)

　Re[1]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ やじゅ (1514回)-(2010/02/06(Sat) 23:09:45)

■No46615 (season さん) に返信

ネットに繋がらないと業務に支障がきたすのは気にしなくてもいいのかな。
回線によっては、結果が返ってくるまで遅延が発生するよね。

ビジネスロジックは、Windows FormアプリケーションでもDLLにすれば
分離は可能だし、配布もClickOnce使えば容易です。

引用返信 編集キー/

■46624 / inTopicNo.3)

　Re[1]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ .SHO (1194回)-(2010/02/07(Sun) 08:52:43)

■No46615 (season さん) に返信

> サーバーはWindows Server 2003を用意することになっていまして、

>
> ＜デメリット＞
> ・Webサーバーがないと動かない。

上の２文は矛盾してますね。

引用返信 編集キー/

■46627 / inTopicNo.4)

　Re[2]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (2回)-(2010/02/07(Sun) 14:49:01)

■No46617 (やじゅさん) に返信
> ■No46615 (season さん) に返信
>
> ネットに繋がらないと業務に支障がきたすのは気にしなくてもいいのかな。
> 回線によっては、結果が返ってくるまで遅延が発生するよね。
>
ありがとうございます。

確かにWebサービスを利用すると、
ネットに繋がらないと業務に支障をきたすことになりますね。
考えませんでした。

ただ、ほとんどの画面でDBへの接続が必須なので、
ネットが繋がらないと、そもそもシステムが動かない状態にあります。
今回のシステムにおいては、デメリットにならなそうです。

> ビジネスロジックは、Windows FormアプリケーションでもDLLにすれば
> 分離は可能だし、配布もClickOnce使えば容易です。
>
ビジネスロジックはDLL化すれば、分離できますね。
ありがとうございます。

配布はClickOnceの使用を検討してみます。

引用返信 編集キー/

■46628 / inTopicNo.5)

　Re[2]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (3回)-(2010/02/07(Sun) 14:50:27)

■No46624 (.SHO さん) に返信
> ■No46615 (season さん) に返信
>
>>サーバーはWindows Server 2003を用意することになっていまして、
>
>>
>>＜デメリット＞
>>・Webサーバーがないと動かない。
>
> 上の２文は矛盾してますね。
>
ありがとうございます。

確かに矛盾した書き方になっていますね。
すいません。
今回の顧客にはWebサーバーが用意されているので、
自由に使えるのです。
ただ、今後は用意されていないかもしれないため、
購入してもらう必要が出るかもしれない。
という点をデメリットとして記載しました。

ありがとうございます。

引用返信 編集キー/

■46630 / inTopicNo.6)

　Re[3]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ .SHO (1195回)-(2010/02/07(Sun) 16:43:33)

■No46628 (season さん) に返信

> ただ、今後は用意されていないかもしれないため、
> 購入してもらう必要が出るかもしれない。
> という点をデメリットとして記載しました。

インターネット上にサーバを置くのではなく
顧客のローカルLAN内にサーバを置くということでしょうか？

それだと、こんどはメリットの

> ・ビジネスロジックを修正しても、配布が容易。

と矛盾しますね。
（もしくはたいしたメリットではない。）

引用返信 編集キー/

■46633 / inTopicNo.7)

　Re[1]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ 甕星 (2回)-(2010/02/07(Sun) 21:24:26)

処理が早くなり得ると言うメリットもありますよ。DBサーバーとネットワーク的に近い場所でビジネスロジックを実行する事になるります。ビジネスロジック部分でDBサーバーに頻繁なアクセスをともなう場合、ネットワーク的に遠くにあるクライアント上で実行するよりも、WEBサーバー上で実行したほうが早くなります。

処理が遅くなり得ると言うデメリットもあります。ビジネスロジック処理をサーバー側でおこなうので、クライアント数が多い場合、サーバーの負担が大きくなります。結果的に遅くなる可能性があります。

・・・というあたりで察してほしいのだけど、メリットデメリットというものの多くは表裏一体にあるものです。個々の事象は状況次第でメリットにもデメリットにもなり得るのですよ。

例えば「クライアントのOSがWindows以外になっても、ビジネスロジックは修正しなくて良い。」というのは、逆に言えば「Windows以外のOSでの動作も考慮するために、テスト工数がｎ倍になる」事を意味しています。テスト工数がｎ倍になるなんて受け入れられないので、結局はWindowsしか保証しなかったりするのが常です。

引用返信 編集キー/

■46641 / inTopicNo.8)

　Re[2]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ みきぬ (772回)-(2010/02/08(Mon) 09:46:31)

＜メリット＞
・何かあったとき、サーバ側にあるものは調査しやすい。

クライアント側からどう情報を集めるか、いつも悩むんだよなあ。

引用返信 編集キー/

■46642 / inTopicNo.9)

　Re[3]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ 中博俊 (1353回)-(2010/02/08(Mon) 10:00:28)

■No46641 (みきぬさん) に返信
> ＜メリット＞
> ・何かあったとき、サーバ側にあるものは調査しやすい。
>
> クライアント側からどう情報を集めるか、いつも悩むんだよなあ。

そういう意味でWebサービス化すると絶対そことの間には通信が挟まるために疎結合なシステムを作りやすくなりますよね。
ただクライアントアプリとWebサービスのバージョニングなんかもあるので、一概にそのほうがいいわけでもないですが。

引用返信 編集キー/

■46645 / inTopicNo.10)

　Re[4]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ .SHO (1196回)-(2010/02/08(Mon) 11:32:48)

>・何かあったとき、サーバ側にあるものは調査しやすい。

今回の場合、既にあるサーバにのっかるみたいだし
何かあったときは、サーバを停止せずに（さらにあまり負荷もかけずに）
調査・修正が必要になるかも知れないですね。

> ただクライアントアプリとWebサービスのバージョニングなんかもあるので、一概にそのほうがいいわけでもないですが。

基本的には、保守は複雑（面倒）になるでしょう。
自分なら、意味もなくクライアント・サーバ型になんかしたくないですね。

引用返信 編集キー/

■46653 / inTopicNo.11)

　Re[4]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ みきぬ (773回)-(2010/02/08(Mon) 13:10:31)

※サーバの負荷については一切考えてません。

■No46642 (中博俊さん) に返信
> ただクライアントアプリとWebサービスのバージョニングなんかもあるので、一概にそのほうがいいわけでもないですが。

バージョン管理という点で見ても、ビジネスロジックはサーバで持ったほうがいいんじゃないかなと。

ビジネスロジックの修正って、確実に反映させないとまずい気がするわけで、
サーバで管理しとけば、モジュールを交換してワーカプロセスをリサイクルすればその時点から最新になる（乱暴だけど）
クライアントに置いた場合、旧バージョンのビジネスロジックが動く可能性があるわけで、新旧のロジックが混在する状況はあまり考えたくない。

UIなんかは、多少古くても使い勝手か操作が開放される/されないの違いくらいなので
多少古いバージョンが動いててもさほど影響はない。（…たぶん）

つまるところ、サーバは100%管理できるけどクライアントはそうではないところがキモじゃないかなと。

引用返信 編集キー/

■46654 / inTopicNo.12)

　Re[5]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ 中博俊 (1355回)-(2010/02/08(Mon) 13:12:15)

> ビジネスロジックの修正って、確実に反映させないとまずい気がするわけで、
> サーバで管理しとけば、モジュールを交換してワーカプロセスをリサイクルすればその時点から最新になる（乱暴だけど）
> クライアントに置いた場合、旧バージョンのビジネスロジックが動く可能性があるわけで、新旧のロジックが混在する状況はあまり考えたくない。
> UIなんかは、多少古くても使い勝手か操作が開放される/されないの違いくらいなので
> 多少古いバージョンが動いててもさほど影響はない。（…たぶん）

I/Fが変わらない限りにおいてはそうですね。

逆にI/F変えて古いクライアントが動くことを強制的に止めることもできますが^^

引用返信 編集キー/

■46681 / inTopicNo.13)

　Re[4]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (4回)-(2010/02/09(Tue) 10:06:18)

■No46630 (.SHO さん) に返信
> ■No46628 (season さん) に返信
>
>>ただ、今後は用意されていないかもしれないため、
>>購入してもらう必要が出るかもしれない。
>>という点をデメリットとして記載しました。
>
> インターネット上にサーバを置くのではなく
> 顧客のローカルLAN内にサーバを置くということでしょうか？
>

はい、顧客のローカルLAN内にサーバーを置きます。

> それだと、こんどはメリットの
>
>>・ビジネスロジックを修正しても、配布が容易。
>
> と矛盾しますね。
> （もしくはたいしたメリットではない。）

ClickOnceで配布すれば良いということでしょうか。
確かに配布はさほど難しくないかもしれませんね。

ありがとうございます。

引用返信 編集キー/

■46682 / inTopicNo.14)

　Re[2]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (5回)-(2010/02/09(Tue) 10:08:53)

■No46633 (甕星さん) に返信
> 処理が早くなり得ると言うメリットもありますよ。DBサーバーとネットワーク的に近い場所でビジネスロジックを実行する事になるります。ビジネスロジック部分でDBサーバーに頻繁なアクセスをともなう場合、ネットワーク的に遠くにあるクライアント上で実行するよりも、WEBサーバー上で実行したほうが早くなります。

そうですね。
この考えもなかったです。
今回はDBサーバーに頻繁にアクセスしますので、とても参考になりました。

>
> 処理が遅くなり得ると言うデメリットもあります。ビジネスロジック処理をサーバー側でおこなうので、クライアント数が多い場合、サーバーの負担が大きくなります。結果的に遅くなる可能性があります。

今回はクライアント数は20台程度で、極端に大きな負荷を掛ける処理もないため、
サーバー側の負担が大きくなりすぎるということはない見積もりになっています。

>
> ・・・というあたりで察してほしいのだけど、メリットデメリットというものの多くは表裏一体にあるものです。個々の事象は状況次第でメリットにもデメリットにもなり得るのですよ。
>
確かにそうですね。

> 例えば「クライアントのOSがWindows以外になっても、ビジネスロジックは修正しなくて良い。」というのは、逆に言えば「Windows以外のOSでの動作も考慮するために、テスト工数がｎ倍になる」事を意味しています。テスト工数がｎ倍になるなんて受け入れられないので、結局はWindowsしか保証しなかったりするのが常です。

大変参考になりました。

引用返信 編集キー/

■46683 / inTopicNo.15)

　Re[3]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (6回)-(2010/02/09(Tue) 10:09:40)

■No46641 (みきぬさん) に返信
> ＜メリット＞
> ・何かあったとき、サーバ側にあるものは調査しやすい。
>
> クライアント側からどう情報を集めるか、いつも悩むんだよなあ。

エラーログをサーバー側に記録すれば、調査し易いですね。
この考えもなかったです。
参考になりました。

ありがとうございます。

引用返信 編集キー/

■46684 / inTopicNo.16)

　Re[4]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (7回)-(2010/02/09(Tue) 10:11:07)

■No46642 (中博俊さん) に返信
> ■No46641 (みきぬさん) に返信
>>＜メリット＞
>>・何かあったとき、サーバ側にあるものは調査しやすい。
>>
>>クライアント側からどう情報を集めるか、いつも悩むんだよなあ。
>
> そういう意味でWebサービス化すると絶対そことの間には通信が挟まるために疎結合なシステムを作りやすくなりますよね。
> ただクライアントアプリとWebサービスのバージョニングなんかもあるので、一概にそのほうがいいわけでもないですが。

クライアントアプリとWebサービスのバージョンを合わせる必要がある
ということですよね？

確かにこれを意識する必要が出てくるので、
管理が複雑になる可能性はありますね。
参考になりました。

引用返信 編集キー/

■46685 / inTopicNo.17)

　Re[5]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (8回)-(2010/02/09(Tue) 10:13:49)

■No46645 (.SHO さん) に返信
> >・何かあったとき、サーバ側にあるものは調査しやすい。
>
> 今回の場合、既にあるサーバにのっかるみたいだし
> 何かあったときは、サーバを停止せずに（さらにあまり負荷もかけずに）
> 調査・修正が必要になるかも知れないですね。
>
>>ただクライアントアプリとWebサービスのバージョニングなんかもあるので、一概にそのほうがいいわけでもないですが。
>
> 基本的には、保守は複雑（面倒）になるでしょう。
> 自分なら、意味もなくクライアント・サーバ型になんかしたくないですね。
>
言われてみて、保守が複雑になるなと感じました。

それでなのですが、クライアント・サーバー型にしないということは、
Webアプリケーションを作るということでしょうか？
ASP.NETやSilverlightということでしょうか？
うまくイメージできなかったため、教えてください。

引用返信 編集キー/

■46686 / inTopicNo.18)

　Re[5]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (9回)-(2010/02/09(Tue) 10:15:44)

■No46653 (みきぬさん) に返信
> ※サーバの負荷については一切考えてません。
>
> ■No46642 (中博俊さん) に返信
>>ただクライアントアプリとWebサービスのバージョニングなんかもあるので、一概にそのほうがいいわけでもないですが。
>
> バージョン管理という点で見ても、ビジネスロジックはサーバで持ったほうがいいんじゃないかなと。
>
> ビジネスロジックの修正って、確実に反映させないとまずい気がするわけで、
> サーバで管理しとけば、モジュールを交換してワーカプロセスをリサイクルすればその時点から最新になる（乱暴だけど）
> クライアントに置いた場合、旧バージョンのビジネスロジックが動く可能性があるわけで、新旧のロジックが混在する状況はあまり考えたくない。
>
ありがとうございます。
ビジネスロジックの修正を確実に反映できるのは、確かに大事だと思いました。

> UIなんかは、多少古くても使い勝手か操作が開放される/されないの違いくらいなので
> 多少古いバージョンが動いててもさほど影響はない。（…たぶん）
>
今回のシステムにおいても、問題ないと思います。

> つまるところ、サーバは100%管理できるけどクライアントはそうではないところがキモじゃないかなと。

大変参考になりました。

引用返信 編集キー/

■46687 / inTopicNo.19)

　Re[6]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲▼■

□投稿者/ season (10回)-(2010/02/09(Tue) 10:17:08)

■No46654 (中博俊さん) に返信
>>ビジネスロジックの修正って、確実に反映させないとまずい気がするわけで、
>>サーバで管理しとけば、モジュールを交換してワーカプロセスをリサイクルすればその時点から最新になる（乱暴だけど）
>>クライアントに置いた場合、旧バージョンのビジネスロジックが動く可能性があるわけで、新旧のロジックが混在する状況はあまり考えたくない。
>>UIなんかは、多少古くても使い勝手か操作が開放される/されないの違いくらいなので
>>多少古いバージョンが動いててもさほど影響はない。（…たぶん）
>
> I/Fが変わらない限りにおいてはそうですね。
>
> 逆にI/F変えて古いクライアントが動くことを強制的に止めることもできますが^^
>
I/Fが変わるとクライアントは動かなくなりますね。。
これを良しとするか、しないかは悩みどころです。

今まで考えてなかったです。。

引用返信 編集キー/

■46688 / inTopicNo.20)

　Re[7]: ビジネスロジックをWebサービス化することのメリット、デメリ

▲　■

□投稿者/ はつね (1187回)-(2010/02/09(Tue) 10:49:01)

■No46687 (season さん) に返信
>>I/Fが変わらない限りにおいてはそうですね。
>>
>>逆にI/F変えて古いクライアントが動くことを強制的に止めることもできますが^^
>>
> I/Fが変わるとクライアントは動かなくなりますね。。
> これを良しとするか、しないかは悩みどころです。

よしとするなら既存WEBメソッドを変えちゃう。よしとしないときは新規にWEBメソッドを作成する。
という方針もありますね。
実際に業務で適用した感じでは、WEBサービスのIFが変わるくらいの変更はクライアント側の変更
もそもそも必要だったりするケースが多いので、既存WEBメソッドを変更しちゃって古いクライア
ントは動かなくなってくれた方が助かります。

引用返信 編集キー/

次の20件＞
トピック内ページ移動 / << 0 | 1 >>

- Child Tree -