初心者が簡単に始められるようにするために、ここでは、.NET 初心者の急速な上達に特化した、いくつかの共通の技術的なポイントについて説明する興味深い方法を引き続き使用します。知識は共通ですが、鍵となるのは学ぶという考え方です。テクノロジーは生活から生まれ、このようにしてテクノロジーを学ぶことができます。レンガとモルタルを投げるだけです。
階層構造は現実社会のいたるところで見られます。ある村長が妻に誇らしげに自慢したというジョークがあったのを覚えている。「中国で私よりも高い役職に就いているのは郷長、県長、省長、州首相の4人だけだ」評議会。」このジョークは現実社会の階層化現象も反映している。社会の人々も階層化され、会社の人事構造も階層化され、饅頭を作る籠も階層化される。レイヤリングの目的はさまざまですが、それらはすべて特定の問題を解決するために作成されます。したがって、階層構造は実際には、ある問題を解決するために作成されたソリューションです。
最も一般的に使用されるソフトウェア システムは、一般に 3 層アーキテクチャについて説明します。実際、ビジネス アプリケーション全体はプレゼンテーション層、ビジネス ロジック層、データ アクセス層などに分割されます。ビジネスの詳細、さまざまな機能コード 分散化は、システムの設計と開発にさらに役立ち、同時に、起こり得る変更に対してより小さな単位を提供するため、システムの保守と拡張に非常に役立ちます。
一般的な 3 層アーキテクチャは、図 1 に示すように、基本的に次の部分で構成されます。
図 1 一般的な 3 層アーキテクチャ
データ アクセス レイヤー DAL: データベースとの対話とアクセスを実装し、データベースからデータを取得したり、データベースにデータを保存したりするために使用されます。
ビジネス ロジック層 BLL: ビジネス ロジック層は上位層と下位層を接続し、ビジネス目標を達成するために上位層と下位層のインタラクティブ データを論理的に処理するために使用されます。
プレゼンテーション層 Web: 主にユーザーとのインタラクションを実装し、ユーザーのリクエストを受信したり、ユーザーがリクエストしたデータ結果の表示を返したりしますが、特定のデータ処理はビジネス ロジック層とデータ アクセス層に任されます。
日常の開発では、共通のものを再利用するために、各層で使用されるものの一部を抽象化することが多くなります。たとえば、モデルと呼ばれる複数のレイヤーを通過させるために、データ オブジェクトのエンティティとメソッドを分離します。データ検証やキャッシュ処理、暗号化・復号化処理など、共通の汎用補助クラスやツールメソッドの一部も、Commonと呼ばれる各層間での再利用を可能にするために別途分離され、独立したモジュールとして使用されます。
この時点で、3 層アーキテクチャは図 2 に示す状況に発展します。
図 2 3 層アーキテクチャの進化結果
ビジネス エンティティ モデル: エンティティ クラスのデータ構造をカプセル化するために使用され、通常、ビジネス内に存在するオブジェクトを客観的に記述するためにデータベースのデータ テーブルまたはビューをマッピングするために使用されます。モデルは、分離を改善し、階層化の役割をより適切に果たし、再利用と拡張を改善し、柔軟性を強化するために分離されています。
共通クラスライブラリ Common: 汎用補助ツールクラス。
データベースの一般的な操作をデータ操作クラス (DbHelperSQL など) に抽象的にカプセル化し、再利用を改善し、コードを簡素化できます。データ層の最下層は、一般的なデータベース操作クラスを使用してデータベースにアクセスします。最終的な完全な 3 層アーキテクチャを図 3 に示します。
図 3 最終的な完全な 3 層アーキテクチャ
データベース アクセス クラス は ADO.NET のカプセル化であり、一般的に使用されるいくつかの反復的なデータベース操作をカプセル化します。たとえば、Microsoft のエンタープライズ ライブラリ SQLHelper.cs、Dongsoft の DBUtility/DbHelperSQL などは、データベースにアクセスするための補助ツール クラスを DAL に提供します。
上記の分析を通じて、現在一般的に使用されている 3 層アーキテクチャがどのようなものであるかがわかります。同時に、3 層アーキテクチャが使用されている間の進化プロセスの一部もわかります。では、なぜこのように階層化されているのか、また各層の構造の役割は何でしょうか?読み続けてみましょう。
豚肉の価格は常に上昇しており、プログラマーは、コードを書くことに未来はない、豚を飼うほうがよい、と言う人もいると言われています。豚の飼育には技術的な内容はなく、コードを書くよりも簡単だとは考えていません。実際、豚の飼育はコードを書くほど技術的なものではありません。 3 層アーキテクチャをよりよく理解するために、養豚を例に挙げてみましょう。ことわざにあるように、「豚肉を食べたことがない人は、豚が走っているのを見たことがありません。」
図 4 は、3 層アーキテクチャを備えた養豚産業の組立ラインの興味深い図です。
図4 三層構造と養豚
図 3 と図 4 を比較すると、次のことがわかります:
データベースは豚舎のようなものです。すべての豚は、エリアまたは番号ごとに異なる豚舎に順番に保管されます。
DALは屠殺場のようなものです。豚舎から豚を取り出して、必要に応じて部位(圃場)を取り出したり、分類して整理(統計)して一箱の豚肉を作ります。データセット)を食品加工工場(BLL)に送信します。当初はここで豚を捕まえるのも殺すのも同じ人が担当していましたが、効率が悪すぎると感じたので、豚を捕まえる担当者(DBUtility)を何人かに出して、指定された豚を捕まえるようにしました。要件に。
BLLは、豚肉をさまざまな食用食品に深く加工する食品加工工場のようなものです。
Web はショッピング モール のようなもので、食品を販売できる美しい製品にパッケージ化し、顧客に表示します (UI プレゼンテーション層)。
豚肉はモデルのようなものです。どの工場(レベル)であっても、すべてのリンクで提供されるエッセンスは豚肉であり、豚肉は全工程を貫いています。
共通クラスライブラリ Commonは、作業者が使用する様々な工具に相当し、肉切り包丁、ロープ、ハサミ、梱包箱、ツールカートなどの共通の工具(クラス)を工場(レベル)ごとに提供します。実際には、各部門が独自のツールを作成することもできましたが、それは効率が低く、専門的ではなく、多くの作業が繰り返されることになるでしょう。そこで、誰かがこのような工場を開設して、これらのツールを製造し、それをさまざまな工場に提供することで、工場は自分たちの業務に集中できるようになりました。
もちろん、これは単なる比喩であり、実際の状況は詳細には異なります。この例では、豚小屋からショッピング モールへの一方向のプロセスのみを示しています。実際の 3 層開発では、データのやり取りは双方向であり、取得または保存できます。しかし、豚を一方の端から追い込む機械があり、反対側の端からハムが出てくるという。ハムソーセージが売れない場合は反対側から入れ直すとそのまま豚が出てくる まさか三層に繋がっているとは思いませんでした。構造。上記は単なる冗談ですが、これにより 3 層アーキテクチャの基本概念が理解しやすくなります。
ここまで述べましたが、データベースからコンテンツを直接取得して直接操作できないのではないかと疑問に思う人もいるかもしれません。なぜわざわざ 3 層アーキテクチャを使用するのでしょうか? 3 層アーキテクチャの利点は何ですか?
階層化をしなくても、もちろん可能で、全工程が屠殺場や加工場などに分かれていないのと同じように、すべての作業(屠殺・加工・販売)が同じ場所(工場)で完結します。しかし、なぜ加工工場やショッピングモールなのでしょうか?なぜなら、比較的規模が大きくなると管理が非常に煩雑になり、このような飼育方法では規模のニーズに応えられなくなるからです。さらに、社会発展の観点から見ると、社会的分業は人類の進歩の現れです。社会的分業の利点は、適任者が得意なことを行うことができ、平均的な社会的労働時間が大幅に短縮され、生産効率が大幅に向上することです。高品質で効率的な労働生産物を提供できる者だけが、市場競争において高い利益と高い価値を獲得できるのです。人の才能を生かし、素材を最大限に活用することの最も深い意味は、社会の分業にあります。ソフトウェア開発でも同様で、小規模なプロジェクトに取り組む場合、階層化するかどうかに違いはなく、より面倒で冗長に思えます。しかし、プロジェクトが大きくなり、より複雑になると、階層化の利点が現れます。したがって、階層に分けるか否かはプロジェクトの実情に依存するため一概には言えません。
関連資料: 階層化開発アイデアと小籠包
以上が三重建築と養豚の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。