4

私は現在、コンピューター サイエンスの学位の最終年度に向けて勉強しており、最終的なプロジェクトと論文に取り組んでいます。ASP.NET Web フォームと C# を使用して 3 層プロジェクトを作成します。これを 3 層と呼ぶことはできません。これは、テスト用のローカル PC 以外でホストされることはほとんどないためです。単一の目的のみ。

私の主な質問はこれです：

私の理解では、3 層の考え方は、BLL が DAL を参照し、UI が BLL を参照して、懸念事項を完全に分離することです。ただし、いくつかのチュートリアルに従って小さなモックアップ プロジェクトを作成したので、3 層のコツをつかみます。ほとんどの基本的なチュートリアルでは、UI と BLL の間の参照が必要です。

たとえば、私が作成したプロジェクトは、非常に基本的な製品とカテゴリ タイプの e コマース システムで、DAL に Product クラスと ProductDAL クラスを作成し、次に BLL に ProductBLL クラスを作成しました。1 つのデータベース テーブルのみを使用するこのセットアップでは (今のところカテゴリは忘れてください)、BLL は UI と DAL の間の一種のインターフェイスとしてのみ機能するように見えます。メソッドは DAL のものとまったく同じで、DAL を呼び出すだけです。バージョン。

問題は、BLL 経由で DAL にアクセスするには、Product オブジェクトを BLL メソッドの引数に渡す必要があることです。これは、最初に UI で Product オブジェクトを作成することを意味し、UI から DAL を参照することを意味します。これは正しいやり方ですか？

このような単純なケースを回避するには、適切なフィールド (文字列や int など) を受け取って製品オブジェクトを作成し、それを AddProduct メソッドに返すメソッドを BLL で作成します。ただし、UI でさまざまな製品属性をラベルにバインドする場合は、やはり Product オブジェクトにアクセスする必要があります。

基本的に、製品オブジェクトのプロパティにアクセスするには、BLL でメソッドをロードする必要がありますか? そうでない場合、実際にどのようなメソッドがそこに入るのですか? この種の製品シナリオで BLL に入る可能性のあるメソッドの例を教えてください。

事前に感謝します。これが以前に尋ねられた場合はお詫び申し上げます。私は 3 層アーキテクチャに関する多くの投稿を読みましたが、ほとんどは非常に基本的なもので、1 つのテーブルにしかアクセスできません。

4

2 に答える 2

3

BLL は、UI と DAL の間の一種のインターフェイスとしてのみ機能するようです

これは、このアプリケーションが非常に単純であるためです。現時点では CRUD インターフェイスのみです。より複雑なアプリケーションには、BLL にカプセル化されるビジネス ルールがあります (UI や DAL にはありません)。

Product オブジェクトを BLL メソッドの引数に渡す必要があります。これは、最初に UI で Product オブジェクトを作成することを意味し、UI から DAL を参照することを意味します。これは正しいやり方ですか？

さて、ここにはいくつかの異なるオプションがあります：

  • 異なるレイヤー間で共有さProductれるデータ アクセス オブジェクト (DAO) を持つことができます。このオブジェクトは DAL オブジェクトではありませんが、DAL が使用します。これはDTO - データ転送オブジェクトと呼ばれます。
  • UI によって消費されるオブジェクト、BLL によって消費されるオブジェクト、および DAL によって消費されるオブジェクトを複数持つことができProduct、異なるオブジェクト間で変換するマッピング レイヤーを使用できます。
  • 上記のいくつかの組み合わせ。
于 2012-10-28T11:55:34.990 に答える
0

懸念事項を分離する一般的な方法は、YourProject.Entities などと呼ばれるプロジェクトを作成することから始めることです。これにはメイン クラスの定義が含まれており、顧客や製品などの大きなエンティティを取得する必要がある場合に参照します。並行して、リポジトリとして機能する別のプロジェクトがあります。使用しているテクノロジーに応じて、EF などを実装して DB からオブジェクトを取得するか、ストレート SQL またはストアド プロシージャを使用して DB に直接クエリを実行するメソッドを含めることができます。

これらのプロジェクトは、主にユーザーの入力に基づいて機能することに注意してください。ユーザーが行動し、プログラムが応答します。ただし、実際のビジネス ロジックは UI やデータ アクセスから分離されているという考え方です。これらのアイデアは好きなように組み合わせることができますが、私の専門的な経験でよく見られるのは、DB アクセス側で行われる基本的なデータ制約の適用と、エンティティ プロジェクトでオブジェクトを作成するときに直接行われるデータ検証です。または、エンティティをパラメーターとして受け取る別の EntitiesValidation プロジェクトで。

別の検証プロジェクトを作成したくない場合は、コンストラクターとプロパティを使用してオブジェクトにビジネス ロジックを直接実装できることに注意してください。コンストラクターは、オブジェクトを作成する前に入力にロジックを適用し、完全なプロパティを使用できます。つまり、これは...

private string myProp    

public string MyProp
{
    get
    {
        // Some code
    }
    set
    {
        // Some code
    }
}

これの代わりに...

public string MyProp { get; set; }

これらのプロパティに関連付けられたデータにアクセスするときにルールを実装できます。

最終的に、これらの質問にはさまざまな方法で答えることができます。この質問へのすべての回答から、最善の方法についてさまざまなアイデアや意見が得られると確信しています。私が常に従う 2 つのルールは、DRY (同じことを繰り返さないこと) とコードの保守性です。ロジックをデータ アクセスから、オブジェクト デザインから UI から分離することで、その時が来たら、プログラムの保守と更新がはるかに簡単になります。それが単なる学校のプロジェクトであっても ;)。

于 2012-10-28T11:59:29.137 に答える