アプリ版:「スタンプのみでお礼する」機能のリリースについて

クラサバとWebアプリの違いについて調べていたところ
http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%A9% …
http://qanda.rakuten.ne.jp/qa2569501.html
この二つのサイトを発見したのですが

1.広義のクラサバの中にWeb系システムが含まれる
2.狭義のクラサバは2層アーキテクチャ、Web系システムは3層アーキテクチャを表す

という意味にとれるのですが
ではDBを使用しないWebアプリは狭義のクラサバであると考えてよいのでしょうか。

A 回答 (5件)

広義のC/S,を私がどう捉えているかについては,No.4と同意見です。


  >クライアントが処理をサーバに依頼するモデルという程度の話
  >UIだとかビジネスロジックだとか言う概念は不要と解釈している

狭義のクラサバ,については違っていて,私は,狭義のクラサバ=2層アーキテクチャと捉えています。
  >狭義のC/SはUIとビジネスロジックが一体化しているからロジック+DBで2層
この説明がそのまま,私のイメージしている狭義のクラサバ=2層アーキテクチャです。

>サーバ側……データ層
>クライアント1…プレゼンテーション層
>クライアント2…ビジネスロジック層
>ということになり3層アプリケーションである、
>ということにはならないのでしょうか。

具体的にどんなシステム例のことを指していらっしゃるのでしょうか。
例えば,Visual Basicのシステムを例に挙げてみます。VBの開発というのは,フォーム(見栄え,プレゼンテーション)と,コントロール(処理,ビジネスロジック)が一体となって配置されるのですよね。クライアント側にプレゼンテーション機能がある,ビジネスロジック機能もある,でもそれぞれを独立した層にはできなかった。UIとビジネスロジックが一体化しているから2層アーキテクチャと呼ばれたわけです。
ということで,プレゼンテーション層とビジネスロジック層が独立していながらともにクライアントに配置されている具体的なシステム例をあげていただいた方が話が早いです。

>所在(本体の)がサーバーの場合
>ロジックとDBは一体化することはあり得ないということでしょうか。

こちらも同様で,ロジックとDBが一体化されてそれぞれ層としては分離できないような具体的なシステム例をあげていただいた方が話が早いです。
それが有望な多層アーキテクチャの姿であるなら「新・2層アーキテクチャ」などと命名してもよいのですけれど,理論的にはこういう階層もあり得るだろう,モデルとしてはこういう層分けもあるんじゃないか,と,空想で多層アーキテクチャの分け方をこねくりまわしていても私はその価値がよく分からないので。

>広義のC/Sは全て3層アーキテクチャ以上でないと成立しないような気が

これは違うんじゃないでしょうか。
仮にもC/Sシステムと呼ばれるものなら,UI機能はまああるだろう,処理機能も当然あるだろう,データ機能ももちろんあるだろう。それは正しいように思います。
でもそれが他とは独立性をもつ「層」として定義できるかどうかは別の観点ですから。
    • good
    • 0
この回答へのお礼

再度のご回答ありがとうございます。
>狭義のクラサバ=2層アーキテクチャと捉えています。
あくまで狭義のC/Sは「UIとビジネスロジックが一体化」という点を重視するのであれば、
ビジネスロジックの所在で狭義のC/Sかそうでないか決定されるというのは間違いではないのでは。(UIをサーバーに置くことは不可能ですので)

>プレゼンテーション層とビジネスロジック層が独立していながらともにクライアントに配置されている具体的なシステム例をあげていただいた方が話が早いです。
自分で言っておいてなんですが、極めて非効率的な構造でしか成立しませんね。
失礼しました。

>ロジックとDBが一体化されてそれぞれ層としては分離できないような具体的なシステム
同様に私の間違いです。
Web.Configに入力データを格納したりすれば一体化ということにはなるのかもしれませんが、こちらも極めて非効率的ですね。

>広義のC/Sは全て3層アーキテクチャ以上でないと成立しないような気が
というのは狭義のC/SでいうUIとビジネスロジックは一体化しないのではないか、という私の誤った考えに基づいたものです。

一度まとめさせていただきます。
-----------------------------
広義のC/S:
クライアントが処理をサーバに依頼するモデルである

狭義のC/S:
1.UIとビジネスロジックが一体化している2層アーキテクチャ{jjon-com様}
2.クライアントにアプリ本体(処理系)があるC/Sシステム(処理のすべてがクライアント側にある必要はない){edp3142様}

Web系システム:
>HTTPプロトコルとHTMLを用いて(つまりインターネット技術を用いて)構築されたシステム

その他:
>このような場合はリッチクライアントとして分類する方が判りやすいですね
狭義のC/Sとリッチクライアントは別物と考えた方がよい。(ただし一般的にC/Sといった場合、リッチクライアントを示している可能性はある)

>サーバ側1とサーバ側2に分かれているのは本質ではありません。1つのサーバにまとまっていても3層アーキテクチャです
物理的な配置は「層の数」に影響しない。
-----------------------------
こんな認識でよろしいでしょうか。

お礼日時:2009/10/27 10:22

んー、なんだか皆(私も含めて)あやふやですね。


「n層」と言った時に論理的な層(ユーザインタフェース、ビジネスロジック、データ)と物理的な配置とを明確にせずに語っているから、悪いんでしょうね。

とりあえずですが、#2さんのご回答が一番的を射ているので、そっくり下記引用します。

>2層アーキテクチャと3層アーキテクチャの違いは,ビジネスロジック層がどこに位置づけられるかの違いです。

つまりここで言う層は物理的な配置によって分かれる層の数をもって「2層」とか「3層」と言っています。

---

>これはクラサバというよりWeb系システムの範疇に入るのでは?
>業務ロジックの所在がクラサバかwebかを分けているかと。

いいえ。
Webシステムの定義は「HTTPプロトコルとHTMLを用いて(つまりインターネット技術を用いて)構築されたシステム」です。
物理層の配置状況によってWeb系かC/Sかが区別されるのではないのです(少なくとも狭義では)。

>個人的には広義のC/Sは全て3層アーキテクチャ以上でないと成立しないような気がしてしまったのですが。

広義のC/Sについては、ご質問の際に提示されていた Wikipedia を、私も参考にしました。これによるともっと広い概念だと解釈しました。
つまりクライアントとサーバがあり、クライアントが処理をサーバに依頼するモデルという程度の話です。対照的な例としてピアツーピアが挙げられていますね。よって、私は広義のC/SにはUIだとかビジネスロジックだとか言う概念は不要と解釈しているのですが。

>所在(本体の)がサーバーの場合ロジックとDBは一体化することはあり得ないということでしょうか。

論理的な層で言うなら当然ありえないですが、同じサーバに同居させるという物理的な配置はありえますね。
    • good
    • 0
この回答へのお礼

再度のご回答ありがとうございます。
>Webシステムの定義は「HTTPプロトコルとHTMLを用いて(つまりインターネット技術を用いて)構築されたシステム」です。
失礼しました、確かにその通りですね。

>クライアントが処理をサーバに依頼するモデル
クライアントが「要求」し、サーバーが「応答」する形式が広義のC/Sであるということですね。

>論理的な層で言うなら当然ありえないですが、同じサーバに同居させるという物理的な配置はありえますね。
こちらも失礼しました、物理的な配置は層の数を決定しないのでしたね。

お礼日時:2009/10/27 09:46

#1です。

まず元のご質問に立ち返って

広義のクラサバの中にWeb系システムが含まれる
 →OKです。
狭義のクラサバは2層アーキテクチャ、Web系システムは3層アーキテクチャを表す
 →そうとは限りません。

システムが何層に分かれるかは、サーバ側の構築の仕方によりますので、クラサバであっても3層以上の場合もありえます。小規模なシステムは2層で十分である場合が多いですが。
ですから、私のような開発者は、クラサバシステムの開発依頼が来た場合、求められている構成(何層に分けたいか・分けるべきか)を必ず意識します。設計の仕方が変わってきますからね。

以上を踏まえて、狭義のクラサバの定義を考えると、

>狭義のクラサバの定義は
>1.2層アーキテクチャ(これは語弊?)
>2.リッチクライアント(これはクラサバと呼ばずリッチクライアントと呼ぶべき)
>3.クライアントにアプリ本体(処理系)があるC/Sシステム(正)
>この三つの意味合いで使用されることがあるという認識でよろしいでしょうか。

1./2.ですが、
クラサバ即2層であるとか、クラサバとリッチクライアントが同義である、という言い方は、少し乱暴かなぁと思います。

3.ですが、
これはその通りです。一点補足するならば、処理のすべてがクライアント側にある必要はありません。処理の一部例えば簡単な入力検証などがクライアントにあり、業務ロジックがアプリケーションサーバに構築されている事はよくあります。
    • good
    • 0
この回答へのお礼

再度の回答ありがとうございます。
>処理の一部例えば簡単な入力検証などがクライアントにあり、業務ロジックがアプリケーションサーバに構築されている事はよくあります。
これはクラサバというよりWeb系システムの範疇に入るのでは?
業務ロジックの所在がクラサバかwebかを分けているかと。

>小規模なシステムは2層で十分である場合が多いですが。
個人的には広義のC/Sは全て3層アーキテクチャ以上でないと成立しないような気がしてしまったのですが。

ユーザインタフェース
ビジネスロジック
データベース

狭義のC/SはUIとビジネスロジックが一体化しているからロジック+DBで2層と考えていたのですが。
所在(本体の)がサーバーの場合ロジックとDBは一体化することはあり得ないということでしょうか。

少々混乱してきています。

お礼日時:2009/10/26 18:44

>DBを使用しないWebアプリは狭義のクラサバであると考えてよいのでしょうか。


>層の数が減って3→2になったからクラサバ、というようなものではありません。

DBを使用していなくても層の数は減っていません。3層アーキテクチャ内の1層として数えられているのは(DB層ではなく)データ層です。テキストファイルであっても(強いて挙げれば)メモリ上の構造体であってもデータ層に該当します。
http://ja.wikipedia.org/wiki/多層アーキテクチャ

2層アーキテクチャと3層アーキテクチャの違いは,ビジネスロジック層がどこに位置づけられるかの違いです。

2層アーキテクチャは,ビジネスロジックをクライアント側で実行します。すでに回答があったとおり「そのシステム専用のプログラムがクライアント上で動作している」「クライアントにアプリ本体(処理系)がある」ということです。
  サーバ側……データ層(ただし,ビジネスロジック層の一部分をサーバ側で実行するものも多い)
  クライアント側……プレゼンテーション層,ビジネスロジック層

それに対して3層アーキテクチャは,ビジネスロジック層をサーバ側で集約して実行します。(サーバ側1とサーバ側2に分かれているのは本質ではありません。1つのサーバにまとまっていても3層アーキテクチャです)
  サーバ側1(DBサーバ)……データ層
  サーバ側2(Webサーバ)……ビジネスロジック層
  クライアント側……プレゼンテーション層

------------------------------------------------------------
回答No.1へのお礼に書かれた「狭義のクラサバの定義」は,それで間違っていないと私も思います。ただやはり,リッチクライアントシステムは別にしておきたいですね。

「そのシステム専用のプログラムがクライアント上で動作している」と言うとき,それはあらかじめインストールしておく必要があるものだ,というイメージを持っているからです。
クライアントPC総数が1万台の2層クラサバシステムがある。このシステムでビジネスロジックの変更があったらどうなるか? クライアント1万台に対して専用プログラムの更新作業が必要となる。2層アーキテクチャの最大の弱点がこれです。

それに対してリッチクライアントシステムでは,ビジネスロジック層を実現したクライアントプログラムはサーバ側に置かれており,Webサーバにアクセスするタイミングで最新のプログラムをダウンロードして自動入手します。ビジネスロジックはクライアント側で動作するものの,2層アーキテクチャの最大の弱点を解決している。回答No.1で述べられたとおりハイブリッド型ということになり,昔からあるクラサバのイメージとは違っていますから。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。
>DBを使用していなくても層の数は減っていません。
単純にクライアント + サーバーの数ではないんですね。
>3層アーキテクチャは,ビジネスロジック層をサーバ側で集約して実行します。(サーバ側1とサーバ側2に分かれているのは本質ではありません。1つのサーバにまとまっていても3層アーキテクチャです
であればクラサバは

サーバ側……データ層
クライアント1…プレゼンテーション層
クライアント2…ビジネスロジック層

ということになり3層アプリケーションである、ということにはならないのでしょうか。

お礼日時:2009/10/26 18:24

いいえ。

Webアプリです。
層の数が減って3→2になったからクラサバ、というようなものではありません。

クラサバとWebアプリを比較して論じる場合は、クライアントにそのシステム専用のプログラムを用意するかどうかで切り分けるのが正しいでしょう。
つまり、そのシステム専用のプログラムが、クライアント上で動作している場合はクラサバです。
ブラウザ上で、画面表示に HTML を主に利用してシステムが構成されている場合はWebアプリです(ブラウザは「専用のプログラム」ではなく「汎用のプログラム」と言うべきだからです)。

ブラウザ上で動くけれども、処理本体が Flash や Silverlight を用いている場合には、リッチクライアントと呼ばれます。リッチクライアントはクラサバの範疇に含まれると思いますが、このようなハイブリッド型の構成をとっているものは、どちらに当てはまるか難しいところです(このような場合はリッチクライアントとして分類する方が判りやすいですね)。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。
>クライアントにそのシステム専用のプログラムを用意するかどうかで切り分けるのが正しいでしょう
wikiより
>狭い意味でクライアントサーバと呼ばれる場合には、2層アーキテクチャやリッチクライアントモデルが指される場合がある

狭義のクラサバの定義は
1.2層アーキテクチャ(これは語弊?)
2.リッチクライアント(これはクラサバと呼ばずリッチクライアントと呼ぶべき)
3.クライアントにアプリ本体(処理系)があるC/Sシステム(正)
この三つの意味合いで使用されることがあるという認識でよろしいでしょうか。

お礼日時:2009/10/26 15:11

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!