sql-server - このシナリオでは 2 層が有効な選択肢でしょうか。

Question

このシナリオでは、2 層が有効な選択肢でしょうか。

1. SQL サーバー データベース
2. ビジネスでは、LAN を介した共有データベースへの同時接続数が数百を超えることはありません。
3. 
   (私が信じている) 2 層アプリケーションを開発する労力がはるかに少ないという事実
4. LAN経由で自動化されたクライアントプログラムの更新

Answer 1

最初は開発しやすいかもしれませんが、プロジェクトが内部使用のみの簡単なツールではない場合、長期的にはコストがかかると思います.

3 層が必要かどうかは、プロジェクトを維持する期間と、後で計画している機能や更新の数によって異なります。また、受け入れる (そして修正する) 意思のあるバグの数にも依存する場合があります。IMO 3 層は、より安定したソフトウェアを作成する傾向があります。

Answer 2

2 層ソリューションは開発が容易かもしれませんが、アプリケーションのサイズや複雑性に関係なく、保守が難しくなります。

このアプリケーションがビジネスにとって重要であり、かなりの期間使用される場合、プレゼンテーション、ビジネス ロジック、およびデータ アクセスを独自のレイヤーに分離するために費やされた余分な時間は、それが実現したときに報われると思います。物事を修正したり、ロジックを変更したり、アプリケーションを拡張したりする時が来ます。

これは、おそらく答えと同じくらい多くの異なる意見が得られる質問の 1 つです。

Answer 3

どちらの回答も、3 層が優れたソリューションであることは言うまでもありません。多分

Rockford lhotkaは、特定の状況の費用便益分析が 3 層に有利にならない限り、2 層を使用する必要があると主張しているようです。

彼は言い​​ます：

優れたアーキテクトとして、システムに階層を追加することに引きずり込まれるべきです。

彼が示唆するセキュリティは、3 層ソリューションが明らかに優れている唯一の領域です。

そして彼は次のように主張している.

さらに悪いことに、境界は、システムのソフトウェア設計、ネットワーク インフラストラクチャ、管理性、および全体的な保守性に生の複雑さを追加します。要するに、アプリケーションの層が増えるほど、処理が複雑になり、アプリケーションの構築と維持のコストが直接増加します。

最後に、スケーラビリティに関して、データ アクセスに ado で切断されたレコードセットを使用する場合、デフォルトで接続プールがあり、とにかく高度なスケーラビリティがあるというのが本当かどうか知りたいです。