３層構造アーキテクチャ

質問

プレゼンテーション層、ファンクション層、データベース層と機能を分けて開発したときについてです。

(1)クライアントからAPサーバを介してSQLを発行する方式の場合、SQLを発行しているクラスはデータベース層に含まれるか？ファンクション層に含まれるか？

(2)クライアントからSQLを発行する方式の場合、SQLを発行しているクラスはデータベース層に含まれるか？ファンクション層に含まれるか？

(2)画面からローカルのcsvファイルを読み込む際、
データを保持しておくクラスや、そのメンバーのgetter／setterを実行するクラスはデータベース層に含まれるか？

どこまでをデータベース層として呼んでいますか？

※開発チーム内の文化に依るとは思いますが、
一般的にはどうなのでしょうか？
.

回答No.1

Glory_777 · ベストアンサー

質問者さんの言っている方式は、.NETアーキテクチャに近い思想でしょうか。
機能から、どこの階層であるかを判別するのこと自体が間違っています。
階層とは、簡単に言えば、どこの業界の責任であるかを問うための区分けです。

問題が起きた時、アプリケーション作成者が責任を取るという場合は、
よりローカルな表現である、ブロック、インタフェースと呼ぶのが良いでしょう。
またインタフェース群を取りまとめ、自分たちでメンテナンスしやすく設計する
場合は、設計上で名称以外にもIDをふり、独自のブロック化が必要になります。

この時の用語は、そのチーム内でしか通用しないもとなるでしょう。
なので、この機能は何のブロックに該当するのか、それは自明のはずです。

ソフトウェアの業界では、動作や機能に着目しますが、
大変狭義な分類学であり、
それより大きな分類学に当てはめることはできません。

システム全体の中では、常に、アプリケーション層であり、
ローカルな仕事をする、”その他大勢の人”と言うニュアンスで階層自体が扱われます。

例えば、
クライアントと言うのはクライアント・サーバ方式をさす、システムを分類する
ための用語であり、ソフトウェアとは関係ない別の業界の用語です。

また、
通信だけに特化する場合は、ノードと呼ぶのが正しく、
この世界では、コンピュータもルータも同じものとして扱います。

ソフトウェアは、
こうした別の業界のユーザーであり、実際に”それ”を作った人ではありません。

そうした意味で、インタフェースと呼ぶが正しいでしょう。
また、そのインタフェースを提供しているミドルウェア製品や言語を使用した場合、
それらのユーザーであるプログラマは、

独自のファンクションを作っただけですから、全てがファンクションとなります。

ここからは言外に含むニュアンスです。

三層を定義しているジャンルは、それぞれのデファクトメーカーが違い、
言語や思想も異なるため、連携しやすいように、定義したものであり、
製品を作る他の業界やユーザであるプログラマを識別し、
連携できるようにしたものです。

コンピュータですから、やろうと思えば、質問者さんのいうように
(1)～(3)のどの様な配置も実装も可能です。

しかし、問題が起きた時、通例の使用方法として違うとなれば、
これらのバグ情報は、他の業界で製品を作っているメーカーにとっては、
責任外と成ります。

これが嫌で、層が定義された場合、慣例としての使用の仕方を調査し、
それ以外の使用方法を行わないようにするのが常識とされています。

しかし、単なる分類学と勝手に誤解している人が多くあり、
勝手にプログラム上での機能を配置することは良くあります。

これをさせない管理体制を開発体制と言います。

どこのブロックからどのインタフェースを使用すべきかを検討できると、
上位工程に習熟しているとされます。

これは、問題が起きた時どこのメーカに話すことになり、
解決が早いか？　と言う内容で選択されますので、
技術とは全く関係ない次元になります。

多くのプログラマが上位工程に進めない理由は、
技術的な観点でインタフェースが選択されていると誤解しているからです。

三層構造を採用すると、フリーを基本とした製品群が多くなり、
多様な専門技術者をバックヤードに抱えることになります。
ただし、技術者の数は多いです。メーカも多いですね。

それが故に、体制と言うのが大事になり、担当わけをすることになります。

このときは、コーダーと言う概念があり、この人はフローチャートや
関数仕様の様なものにしたがって、プログラム構造や使用する関数を指定
された上でコーディングします。

関数名や、ライン数も含めて指定されますので、誰が書いても同じです。

インタフェースにSQLを使用するか、どこで発行するかは、
外部設計や内部設計に関わりますが、実際のところは恒久メンテナンス、
顧客事情、セキュリティなど、あらゆる考慮が必要となり、
本来は要件定義やそれ以前の段階でSEとPMが判断します。

しかし、細かい設計上でのインタフェース指定や配置を設定するとコストが
あがりますし、さきほど言ったようにトリッキーすぎると、メーカーが保障
しませんから、

「何々と言ったら、普通はこうする」

と言う一般概念を作ります。

けっして、キーワードからデータをアクセするのでデータアクセス層では
ありません。またSQLを使うからとか、この関数を使うからではないです。

これでは連想ゲームです。
一般通念としての工法をさすので、逸脱した時は、
何物でもないとするのが正しいでしょう。

三層構造と言ったら、トリッキーなことをしないで、なるべく製品を買って
作るやり方と言うニュアンスです。
より、固い人達が使うという印象です。加えて先進的でない。
UNIX系のシステム管理者出身が好みます。

MVCと言ったら、開発環境の構築が面倒だけど、
顧客受けがよい見栄えや、少しくらい複雑な処理ができる安価なシステムを
場合のニュアンスです。
システム系の処理が地味であり、昨今の華やかなITとかけ離れているため、
ギャップを埋めたいと言う、古い業界の中での革新派と言う印象。

それ以外は、顧客ごとにシステム名が定義され、
中身が前述の三層構造であったり、MVCであったり、レガシーであったり、
問わず複合であると言う（大規模な）ニュアンスです。

なのでプログラマが勝手に関数発行場所やインタフェースを考えられる
システム開発は存在しません。

概念としては自由に名前をつけてもいいのですが、
現実的にはそうした仕事が無いので、趣味としての範囲を超えません。

こうしたものをフレームワークと呼び、独自に作って、使ってもらって良いと
しています。しかし、誰も使わないと思いますよ。
保守的な人が支配的です。

層と言う表現は、業界全体や学術ジャンルを指し、

「私たち、彼ら、それ以外の人」と言うときに使うニュアンスでしょう。

ちなみに、あまりにも強大な組織になると、多数の業界に進出しており、
垂直型に一社で全てをまかなえるようになります。

この場合は、業界として連携する必要が無く、独自に階層を定義できます。

Webアーキテクチャでは、三層構造とマイクロソフト構造の二種類に分類され、
マイクロソフトは一社で全ての階層をオールインワンで提供し、
クライアントやサーバ、データベースや言語と言う概念を消し去ろうとして
います。ですので、彼らのアーキテクチャでは三層から派生した用語は使えません。

更に、さきほどの開発体制も、複数の業界が階層を無し、仕事やノウハウを分担して
連携を想定する（つまり多数のメーカーが責任を押し付けあう）ものを意識して
作り上げる体制ですから、一般的なIT業界の体制はマイクロソフトのアーキテクチャ
を使用する場合は必要ありません。

よくご存知の.Netです。

.Netでは設計や思想のようなものを排除し、プログラマが全てを自由に、個人で出来る
ようにする目的が強く、これらをサポートするための技術を集めているようです。

当然ながらSI業界との対立関係にあり、SI業界ではLinux文化の普及により、
抵抗しています。

コードをかけないおっさんは食べていけなくなるじゃないですか・・・。

つまり、”層”には、「慣例にあわせ、独自性をだしてはいけない」と言う思想を持つ場合
に使うと良いとおもいます。

発想の自由による、技術の良さを取りたい場合は、少なくても「.Net的ではあるが」
と前置きすると良いと思いますよ。

つまり、本来自由である社会の中で、仕事を済み分けるためにある言葉が多く、
そこからアカデミックな内容を想像すると、合理性がたもてず、

疑問に思うことが多いはずです。

ITやコンピュータの業界は、学術世界のように精錬されておらず、
デファクト（強い奴が）が正しい。

こうした力関係で言葉が使われているので、
これらの派閥と生い立ち、現状での勢い等を良く考えないと、正しくなくなるわけです。

としたばあい、無理に何かの概念にあわせず、

ローカルな設計書やブロック名、インタフェースのみを語るのが健全。

苦労して覚えた技術用語が単なる政治用語であるというのが多く、

IM●が、仕事をとれたようなので、いまはその概念用語は使わないことになった。
と言うこともあります。

覚えても覚えても、知識が増えないのが、IT用語でしょう。

以上、ご参考になれば

お礼

ありがとうございます。

自分の見えていない世界・視点が見えるようになったと思います。