問題タブ [3-tier]

3層設計は、データベース駆動型アプリケーションの長年の標準的な設計哲学であり、失敗したことはありません。それを実践する人のために、あなたのレイヤーを説明してください。

多くの人がビジネス層とデータアクセス層を混乱させ、2.5層の設計のようになっていることがわかりました。

ストアドプロシージャを使用してデータ層をほぼ完全にデータベースに移動し、sproc呼び出しをビジネスオブジェクトにラップする非常に軽量なデータ層をコードに含めることを好みます。

どのようにアプローチしますか？

編集：3層とは何かを定義するだけの場合は、返信に時間を無駄にしないでください。特定の人がそれをどのように実装したかを探しています。ストアドプロシージャまたはORMを使用しましたか、DALとBLLの間の循環依存関係をどのように処理しましたか？このトピックには、言う以外にも多くの深みがあります

• UI
• 仕事
• データ

多層分離を維持しながら、ASP.net DropDownList をエンティティ フレームワーク クエリの結果にバインドしようとしています。(つまり、UI コードにクエリの詳細を含めたり、データ レイヤー コードに UI の依存関係を含めたりしたくありません。) Page_Load イベント ハンドラーのコード ビハインドは次のようになります。

私のデータ コードは次のようになります (中間のビジネス レイヤーもありますが、まだ処理は行われておらず、パススルーのみです)。

DocTypeDropDownList.DataBind(); に到達すると、「DocTypeDropDownList.DataBind();」というメッセージとともに ObjectDisposedException がスローされます。これに取り組むための最良の方法について誰かが私にアドバイスできますか?

ありがとう、アンディ

ログインページを認証できる簡単な方法。3層アーキテクチャでその認証を行うにはどうすればよいですか? DAL、BAL、および GUI レイヤーにあるべきコードを教えてください。これが私の簡単なコードです：

Web.config:

login.aspx.cs:

ここ数年、私は 3 層アーキテクチャ (プレゼンテーション、ロジック、およびデータ層) を使用してアプリケーションを作成してきました。通常、.netTiers などのツールを使用して、データ層とロジック層の一部を生成しています。すべてがうまく定義されていて、私はそれが大好きです。

私は現在、LINQ to Entites を使用することに制約を受けており (LINQ to SQL は Microsoft によって放棄されたようです)、本当に混乱しています。LINQ to Entites によって生成されたコードは、私がほとんど制御できないロジック層とデータ層が大きく混在しているように見えます。さらに、生成されたクラス (エンティティ...) を使用しなければならないという事実があまり好きではありません。

最後に、LINQ to Entities の経験とベスト プラクティスを共有していただけますか? どうすれば明確に定義された 3 層アーキテクチャを維持できるのでしょうか?

ありがとう！

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

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

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

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

ありがとう

現在、学位プロジェクトの設計に取り組んでいます。数日前、LINQ の勉強を始めました。興味深く、プロジェクトで使用する予定でしたが、ある時点で混乱しています。

LINQ to SQL クラスを追加すると、データベース内の各テーブルに対してエンティティ クラスが自動生成されます。

データベースに 2 つのテーブルがあるとします。

ユーザー
プロジェクト
UserProjects (結合テーブル)

どのユーザーがどのプロジェクトに関連付けられているかを表すジョイント テーブル。

LINQ to SQL クラスは、これら 3 つのクラスを自動生成します。ここで、別の (ユーザーとプロジェクト) クラスをビジネス オブジェクトとして作成するか、これらの自動生成されたエンティティを使用しますか?

また、データベース機能を使用するには、3 層アーキテクチャを使用する必要があります。BLL から LINQ DAL メソッドを直接呼び出すことはできますか?それとも、LINQ DAL のメソッドを呼び出す別の DAL を作成する必要がありますか?

上記のメソッド呼び出しシーケンスは問題ありませんか?

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

ASP.NET2.0Webサイトを開発しています。データアクセスとビジネスロジックのレイヤーを作成しました。現在、プレゼンテーション層では、ビジネス層からデータセットとしてデータを返しています。

私の質問は、データセットまたはオブジェクトコレクション（たとえば、データベース内のカテゴリテーブルを表すCategoryオブジェクト）を使用するかどうかです。データベーステーブル（共通オブジェクト）にマップされるすべてのクラスを定義しました。ただし、プレゼンテーション層のカテゴリテーブルのすべてのレコードが必要な場合があります。私はただ混乱しています。私は何をすべきか？

3 層の .NET 2.0 アプリがあります。プレゼンテーション層は中間層を参照します。中間層はデータベース層を参照します。何らかの理由で、コンパイルすると、データ層の dll がプレゼンテーション層のビンに表示されます。どうすればこれを止めることができますか?

私は本ProASPNET MVC Frameworkを読んでいて、多くのことに本当に混乱しています。私はいくつかの調査を試みてきましたが、非常に多くの異なるアプローチや概念が私に投げかけられているので、それは事態を悪化させているだけだと気づいています。
だから私はいくつかの質問があります：

1. 私はMVCが機能を3つの主要なものに分割することになっていることを知っています：モデル->コントローラー->ビュー。MVCは3層アーキテクチャとは異なるアプローチですか？それとも、プロジェクトにデータアクセス層とビジネスロジック層を作成することをまだ考えているのでしょうか。

2. リポジトリとは正確には何ですか？それは私のデータアクセス層として機能するものですか？リポジトリはMVCのどこに/どのように適合しますか？

3. この本では、LINQ to SQLを使用してデータベースと対話する方法について説明していますが、LINQ to SQLは将来サポートされなくなり、MicrosoftはEntityFramework用に廃止する予定であると述べています。Entity FrameworkはMVCのどこに適合し、どのように操作すればよいですか？

よろしくお願いします！
マット