問題タブ [n-tier-architecture]

編集1

申し訳ありませんが、2つの提案された記事を読んだ後でも、何を使用すべきかわかりません。IQueryableの使用はさまざまな理由で好ましくないことを理解していますが、それによってIEnumerableも削除されますか？DataTableは本当に私の最良の選択肢ですか？

要するに、私は推測します、好ましいリターンタイプは何ですか？

DALに抽象化したい次の単純なLINQクエリがあります。varのタイプは何ですか？したがって、私のメソッドはどのタイプにする必要がありますか？

VSでカーソルを合わせると表示IQueryable<T>されますが、ブレークポイントを設定して実行すると、それ自体がIEnumerableと呼ばれるようです。どちらが正しく、メソッドをどのように宣言する必要がありますか？

このように->

IQueryable<T>何を使用する場合<T>、またはそれをどのように知ることができ、何を返すことができますか？

ありがとう！

参考までに、CopyToDataTable（）を以下に示します。

現在、データセットをデータレイヤーまたはビジネスレイヤーに入れるかどうかについて議論しています。

私の友人は、すべての ADO.NET コンポーネントをデータ層に入れるべきだと考えています。私にとって、これは次の理由から正しくないようです。

• ファット データ レイヤー クライアントを作成すると、たとえば、すべてを別のデータ ソースに移行するのがはるかに難しくなります。
• ビジネス層のロジックをスキップしない限り、バインドされたコントロールを持つことはできません。

データセットとデータテーブルはすべてのデータ プロバイダーに共通であるため、ビジネス ロジックに含める必要があると思います。データ層には、適切なプロバイダーのオブジェクト (接続、データアダプター、トランザクション、データリーダーなど) をインスタンス化するためのプロバイダー ファクトリが必要です。私にとって、これは次の理由から行く方法です。

• 別のデータ レイヤーへの移行は非常に簡単です。
• コントロールを豊富なビジネス オブジェクトにバインドできます

n層の第一人者は、進むべき道を明確にするのに役立ちますか?

Linq-To-Entities クエリを含む多数のリポジトリを上部に持つデータレイヤーとして、Entity Framework を使用した階層化アーキテクチャを使用しています。データ レイヤーは 1 つのプロジェクトで、その隣にはサービス レイヤーと Web サイトであるインターフェイスがあります。

エンティティ モデルの接続文字列を Web サイトで指定する必要があります。どうすればいいですか？

シングルトン メソッドを使用して、データレイヤー内にあるエンティティ リポジトリにアクセスしています。

ありがとう

これが私の状況です。3 層パターン (つまり、プレゼンテーション層、ビジネス層、データ層) にできるだけ従おうとしています。DB からのデータが必要な場合、ビジネス層は情報を返すデータ層を呼び出します。データ層は SqlDataReader または DataTable オブジェクトを返すことはありませんが、多くの場合、データ アクセス層によって認識されるカスタム オブジェクトの列挙を返します。データレイヤーがオブジェクトの少ないリストを返す必要がある場合、これは非常にうまく機能します。

私は現在、この問題に直面しています。アプリケーション (ビジネス層) は 500000 レコードを処理する必要があります。データ レイヤーに別のメソッドを追加して IEnumerable を返すこともできますが、これは非常に悪いように思えます。メモリに 50 万件のレコードをロードしたくありません。

私の質問は、3 層モデルを考慮して、このケースをどのように処理すればよいですか? 3 層パターンがなければ、単純にビジネス クラスで SqlDataReader を使用します。助言がありますか？

UPDATE : データは表示されないため、これはページングの問題ではありません (ここではプレゼンテーション層はまったく関係ありません)。各レコードを分析し、それらの一部を保持するだけです。

ありがとう

n 層アプリケーションのレイヤーにデータを渡すにはどうすればよいでしょうか? 私は3つの異なる方法を計画しました。

A) ジェネリック .net オブジェクト ジェネリック データ テーブル、ハッシュテーブル、ジェネリック データセット、文字列、int など... 次に、データセットを使用して、UI レイヤーに送信されるビジネス オブジェクトを埋めます。

代替テキスト http://img11.imageshack.us/img11/460/generic.png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro-追加のレイヤーは必要ありません Con-ビジネスレイヤーで一般的なデータセットとテーブルを操作する必要があります

B) 他のレイヤーが参照するエンティティ レイヤーを使用する。このレイヤーには、厳密に型指定されたデータセットまたはプレーン オールド C オブジェクトのいずれかが含まれます。オブジェクトはほとんどがコンテナ データで、ロジックはほとんどありません。これらは、UI レイヤーに送信されるオブジェクトと同じです。

代替テキスト http://img8.imageshack.us/img8/6454/entities.png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

すべてのレイヤーで同じクラスを使用するプロ作業 すべてのレイヤー にentities.dllへの参照を追加する

C) DataAccess Layer で定義されたデータ転送オブジェクト (コンテナ オブジェクトのみ) を使用します。次に、これらのオブジェクトを使用して、UI レイヤーに送信されるビジネス オブジェクトを埋めます。

代替テキスト http://img43.imageshack.us/img43/1236/transferp.png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

プロ- ビジネス層は一般的なクラスで 動作する必要はありません 2 種類のオブジェクトを扱う場合、転送オブジェクトでビジネス オブジェクトをハイドレートする必要があります

私たちは職場で議論を行い、コミュニティがどう考えているかを知りたがっていました。ダブルボードへのリンクも追加しました。編集ではなくコピーして作成してください。
ありがとう

私は、すべてのアプリケーションの階層化/n 層化設計の 1 つの方法を標準化するために懸命に取り組んでいます。

すべてのアプリケーションを 5 層にしようとしています。

コード：

| | UI |

| |

| | ビジネス オブジェクト |

| |

| | OR-マッパー |

| |

| | データ アクセス |

| |

| | RDBMS |

ユーザーのログイン/ログアウト機能を備えたアプリケーションを開発しているとします。VS2005 ソリューションで 4 つのプロジェクトを作成しています。各プロジェクトは、上位 4 つのレイヤーのいずれかです。次のようにビジネスオブジェクトクラスを設計しています:-

これが、実際のシナリオに一致する機能をオブジェクトに与える方法です。ここで、GetByUsername() と GetByUserTypeCode() は getter 関数です。これらの関数は、実際のロジックと一致しません。Coz、現実の世界では、ユーザーは「ユーザー名で取得」または「UserTypeCode で取得」することはありません。したがって、これらの関数は静的に保持されます。

OR Mapperレイヤーの私のクラスは次のとおりです:-

最後に、DA クラスは次のとおりです。

誰かがこれらのクラスを詳しく調べると、OR Mapper レイヤーには BusinessObject-layer の参照が必要であることを理解できます。BusinessObject-layer には、OR Mapper-layer の参照も必要です。

これにより、循環依存が作成されます。

この問題を回避するにはどうすればよいですか?

プレーンなデータ転送オブジェクト (DTO) の使用を提案した人がいます。しかし、私の知る限り、OOP によれば、実世界のオブジェクトの属性と機能は、クラスとしてグループ化する必要があります。DTO を使用する場合、どうすれば機能をクラスにカプセル化できますか? さらに、属性 (BO) のない別のクラスを作成しています。私にとって、それは両方の点で OOP の違反です。もしそうなら、OOP はこの世界で何のためにあるのでしょうか。「UserManager」クラスにも同じ答えを適用できます。

ブログを見つけました。

インターフェイスの実装について説明します。別のインターフェースを定義し、それを BusinessObject のデータ クラスに実装し、BusinessObject および OR-Mapper レイヤーのインターフェースに対してプログラムします。

しかし、私はこれを行うことができませんでした。

誰かが実際の例でそれを示すことができますか?

最初に次のスレッドをお読みください。

C# と Visual Studio 2005 のアセンブリ間の循環参照

インターフェースを実装することで問題は解決しますが、目標を達成することはできません。

私の目標は、UI レイヤー/アセンブリからの BO レイヤー/アセンブリのみで動作することです。きれいなレイヤー間の参照を維持できるように。

UIレイヤー/アセンブリのBOレイヤー/アセンブリとORMapperレイヤー/アセンブリの両方に参照を追加したくないので。

UI レイヤー/アセンブリ内から BO レイヤー/アセンブリのみを操作したい。

その間、DIではなくリフレクションを使用することでのみ可能であると誰かが私に提案しました。本当？

BLLでビジネスルールのエラーを返すためのベストプラクティスは何ですか？例外を発生させてプレゼンテーション層でキャッチする必要がありますか？例外タイプ情報を保持するある種のオブジェクトを返す必要がありますか？

私の意見では、そうであり、そうではありません。

1. ロジックとデータを UI から分離しますが、それでもすべてを 1 つのポイント アプリケーションに詰め込みます。
2. コントローラはビ​​ジネス ロジックであり、ビューは UI であり、モデルは DAL であるため、実際にはそうではないと思います。これらは、同じアプリ内の単なるレイヤーになりました。

しかし、層は実際に層と呼ばれる最初または2番目の種類であると思われますか?

自分の 2 セントを追加したい人はいますか?