1

プログラムを 3 層 (BLL、DAL、UI) の n 層アプリケーションに分割する方法を理解するのに苦労しています。私はこの件について非常に混乱しているので、どこから始めればよいかわかりません。動画や記事、応用例などを見てきましたが、わかりにくいと思います。ある例から次の例へと一貫性がないように思われます。この件に関して非常に徹底的に調べたリソースはありますか?

参考までに、私はC# .NET の初心者レベルの開発者ですが、これは今取り組むには大きすぎるトピックですか? 概念は完全に理解していますが、それをうまく実装する方法がわかりません。

4

2 に答える 2

5

まず、3 層設計を検討することをお勧めしますが、実際には 3 層よりも多くの層があるように見えることを知っておいてください。ただし、基本的には 3 層です。

プレゼンテーション層

作成するアプリケーションには、何らかのプレゼンテーション層があります。実際にはプレゼンテーションである場合もあれば、クライアントが期待するデータを返すレイヤーである場合もあります (例: Web サービスの応答、HTML/JavaScript のクライアント UI など)。通常、クライアント側を表すいくつかのクラスがあります。データ多くの場合、ViewModel または単にプレゼンテーション モデルと呼ばれます。ここで重要なのは、データが提示しているビューに固有のものであるということです。例としては、注文番号、注文日、および総コストのみを表示する注文履歴フォームがあります。この特定のビューでは、ユーザー名、品目ごとのコスト、出荷数、税額、配送方法などを知る必要がない場合があります。ViewModel がどのように機能するべきか、また必要かどうかについては、多くの議論があります。それはあなたのアプリに依存します。重要なのは、このアプローチを使用する場合、ViewModel はビュー/ページが使用するデータを保持する単なる軽量クラスであるということです。

ビジネスロジック/ドメイン層

これは、通常、いくつかの部分に分割できるレイヤーです。それらには以下が含まれる場合があります。

  • ドメイン オブジェクトまたはビジネス オブジェクト - ビジネス ロジックのオブジェクト表現です。ドメイン駆動設計 (DDD) およびほとんどすべてのプログラミング パラダイムでは、これはビジネス オブジェクトが存在する場所です。それらは、顧客、注文、アカウントなどを表すクラスである可能性があります。ここで重要なのは、アプリケーションのコンテキストで意味のあるデータの表現であるということです。データベース内のデータや、ユーザーに表示するデータと似ていない場合がありますが、アプリケーションでは意味をなすように構造化されています。
  • リポジトリ - これらは「コレクション」です (実際にはコレクションではない可能性があるため、引用符で囲みます)。データ層の複雑さを隠し、ドメイン オブジェクトのコピーを返します。ここでの考え方は、Order オブジェクトが必要な場合はリポジトリに要求するというものです。たとえば、OrderRepository.FindByDateRange(startDate, endDate)です。繰り返しますが、ここで重要なのは、ビジネス層がデータに直接アクセスする必要がないということです。リポジトリはその複雑さを覆い隠し、データベース、xml、キャッシュなど、データのソースを簡単に変更できるようにします。
  • ヘルパーまたはビジネス/ドメイン ロジック - これらは通常、ビジネス ロジック レイヤーに配置され、ビジネスに固有の処理を行うクラスです。検証、計算、データ操作などが含まれる場合があります。ここで重要なのは、ビジネス レイヤー データを操作し、ビジネス ニーズのコンテキスト内でアクションを実行することです。たとえば、すべての注文に送料無料の項目が 3 つ以上あることを確認する必要があるとします。これはビジネス ルールであり、ビジネス レイヤー内で適用する必要があります。

データレイヤー

データ層は、データ ストアと通信する実際のコードです。ADO.NET や、Entity Framework、nHibernate などのオブジェクト リレーショナル マッパーの場合もあります。これは、SQL やその他のデータ クエリが存在する場所です (もちろん、T-SQL は可能な限りデータベース内にある必要がありますが、アプリケーションの種類、IMO によっては許容されます)。ここで重要なのは、ビジネスとプレゼンテーションです。レイヤーは、データが実際にどこから来たのかについては何も知らず、期待される形式でデータを受け取ることだけを知っている必要があります。このデータ層は、その情報を返すものです。通常、データ層はデータストアにクエリを実行し、データを何らかのクラス (データ エンティティまたはデータ転送オブジェクトと呼ばれることもあります) に入れます。これらは、上記のビジネス オブジェクトを生成するためにリポジトリによって使用されます。

その他のリソース

上記のレイヤーには、たとえば、データ オブジェクトからビジネス オブジェクトを作成するのに役立ついくつかのマッピング クラスもある場合があります。AutoMapper のようなプロジェクトはこれに役立ちますが、確かに私は経験がありません。

ポリモーフィズムとインターフェースについて学ぶことは良い考えです。このレイヤー分離では、抽象化がますます重要になっています。抽象化により、リポジトリはデータベースまたはまったく異なるソースからデータを取得できますが、ビジネス層はどちらを気にするべきではありません。ビジネス層が必要とするのは、期待される形式でデータを取得することだけであり、どこからでも気にする必要はありません。次のことを真剣に検討します: SOLID 設計原則、設計パターン (少なくともリポジトリ、アダプター、ファクトリ)、依存関係逆転原則 (必ずしも制御フレームワークの逆転などではなく、少なくとも依存関係逆転の原則を理解するまで)

覚えとけ：

これは単純化された例であり、おそらく誤った情報と間違いなく悪い設計でいっぱいですが、頭の中でレイヤーを少し分離するのに役立つことを願っています. アーキテクチャについてはさまざまな意見がありますが、結局のところ、私があなたに与えることができる最良の答えは、それは本当に依存しているということです. 通常、上で述べた部分に分けると、始めるのに役立ちます。あなたは環境に配慮した開発者のようですが、がっかりしないでください。何年も毎日何時間も費やしても、ソフトウェアの構築方法に完全に満足することはできません。機能するものに集中し、それが理にかなっているときにリファクタリングします。私はそれを行うための最良の方法を学ぼうとしてきました.何ヶ月も記事を読んでいますが、まだ見つけていません.

頑張って。

于 2013-11-08T17:42:15.837 に答える