4

3層アーキテクチャ（UI、ビジネス、データ）があるとします。通常、データアクセスオブジェクトを保持するために「モデル」または「共通」と呼ばれる4番目のプロジェクトを作成すると、他の各プロジェクトがこのプロジェクトを使用します。

現在、データアクセスオブジェクトの一部に、データプロジェクトへのアクセスを必要とするSave（）などのメソッドがあるプロジェクトに取り組んでいます。したがって、データプロジェクトでモデル/共通プロジェクトを使用しようとすると、循環参照が作成されます。

このシナリオでは、データアクセスオブジェクトを保持するのに最適な場所はどこですか？データプロジェクト自体の中にそれを保持することはできますが、データアクセスオブジェクトについて知る必要がある私のUIプロジェクトは、データレイヤーにアクセスする必要があります。これは良くありません。

4

7 に答える 7

8

私はあなたがあなたのn層を完全に正しく持っているとは思わない。より多くの2層システムを構築しているようです。

実際の3層プロジェクトでは、データ層のみがデータベースとの通信を許可されます。あなたはあなたの「モデル」または「共通」プロジェクトでそれを持っています。これらのプロジェクトはデータ層です。しかし、あなたが方向転換するのは、ビジネス層だけが彼らと話すことを許可されるべきであるということです。プレゼンテーションコードがデータ層プロジェクトと通信することを許可しないでください。

n-Tierは、3つ以上の「層」がある場合に使用されますが、同じ原則が適用されます。各層は、その下の層の使用方法のみを知っており（参照のみが必要）、上の層のAPIを提供します。それ。私自身のプロジェクトでは、あなたの典型的なプレゼンテーション、ビジネス、およびデータの層を取り上げ、ビジネスとデータの間の4番目の「翻訳」層を提供します。このように、データ層はデータセット、データテーブル、データ行などのジェネリック型を返すことができ、ビジネス層は強く型付けされたビジネスオブジェクトに関してのみ機能する必要があります。変換層は、汎用データオブジェクトと強く型付けされたオブジェクトの間でのみ変換します。このように、従来の層の1つに変更を加えると、別の層に変更を加える必要が少なくなります。

于 2009-12-09T00:04:11.450 に答える
2

これが私のプロジェクトにあるものです。

1.）Application.Infrastructure

  • すべてのビジネスオブジェクトの基本クラス、ビジネスオブジェクトコレクション、データアクセスクラス、および拡張メソッドとしてのカスタム属性とユーティリティ、ジェネリック検証フレームワーク。これにより、最終的な.netアプリケーションの全体的な動作構成が決まります。

2.）Application.DataModel

  • データベースの型付きデータセット。
  • TableAdaptersは、トランザクションやその他の必要な機能を組み込むために拡張されました。

3.）Application.DataAccess

  • データアクセスクラス。
  • 基になる型付きデータセットを使用してデータベースアクションが照会される実際の場所。

4.）Application.DomainObjects

  • ビジネスオブジェクトとビジネスオブジェクトコレクション。
  • 列挙型。

5.）Application.BusinessLayer

  • プレゼンテーション層からアクセス可能なマネージャークラスを提供します。
  • HttpHandlers。
  • 私自身のPage基本クラス。
  • もっと多くのものがここに行きます。

6.）Application.WebClientまたはApplication.WindowsClient

  • 私のプレゼンテーション層
  • Application.BusinessLayerおよびApplication.BusinessObjectsから参照を取得します。

Application.BusinessObjectsはアプリケーション全体で使用され、必要に応じてすべてのレイヤーを移動します[Application.DataModelとApplication.Infrastructureを除く]

私のクエリはすべて、Application.DataModelのみで定義されています。

Application.DataAccessは、データアクセス操作の一部としてBusinessオブジェクトを返すか受け取ります。ビジネスオブジェクトは、リフレクション属性を使用して作成されます。各ビジネスオブジェクトは、データベース内のターゲットテーブルへの属性マッピングでマークされ、ビジネスオブジェクト内のプロパティは、それぞれのデータベーステーブル内のターゲット列への属性マッピングでマークされます。

私の検証フレームワークでは、指定されたValidationAttributeを使用して各フィールドを検証できます。

私のフレームワークは、属性を多用して、マッピングや検証などの面倒なタスクのほとんどを自動化します。フレームワークの新機能として新機能を追加することもできます。

サンプルのビジネスオブジェクトは、私のアプリケーションでは次のようになります。

User.cs

[TableMapping("Users")]
public class User : EntityBase
{
    #region Constructor(s)
    public AppUser()
    {
        BookCollection = new BookCollection();
    }
    #endregion

    #region Properties

    #region Default Properties - Direct Field Mapping using DataFieldMappingAttribute

    private System.Int32 _UserId;

    private System.String _FirstName;
    private System.String _LastName;
    private System.String _UserName;
    private System.Boolean _IsActive;

    [DataFieldMapping("UserID")]
    [DataObjectFieldAttribute(true, true, false)]
    [NotNullOrEmpty(Message = "UserID From Users Table Is Required.")]
    public override int Id
    {
        get
        {
            return _UserId;
        }
        set
        {
            _UserId = value;
        }
    }

    [DataFieldMapping("UserName")]
    [Searchable]
    [NotNullOrEmpty(Message = "Username Is Required.")]
    public string UserName
    {
        get
        {
            return _UserName;
        }
        set
        {
            _UserName = value;
        }
    }

    [DataFieldMapping("FirstName")]
    [Searchable]
    public string FirstName
    {
        get
        {
            return _FirstName;
        }
        set
        {
            _FirstName = value;
        }
    }

    [DataFieldMapping("LastName")]
    [Searchable]
    public string LastName
    {
        get
        {
            return _LastName;
        }
        set
        {
            _LastName = value;
        }
    }

    [DataFieldMapping("IsActive")]
    public bool IsActive
    {
        get
        {
            return _IsActive;
        }
        set
        {
            _IsActive = value;
        }
    }

    #region One-To-Many Mappings
    public BookCollection Books { get; set; }

    #endregion

    #region Derived Properties
    public string FullName { get { return this.FirstName + " " + this.LastName; } }

    #endregion

    #endregion

    public override bool Validate()
    {
        bool baseValid = base.Validate();
        bool localValid = Books.Validate();
        return baseValid && localValid;
    }
}

BookCollection.cs

/// <summary>
/// The BookCollection class is designed to work with lists of instances of Book.
/// </summary>
public class BookCollection : EntityCollectionBase<Book>
{
    /// <summary>
    /// Initializes a new instance of the BookCollection class.
    /// </summary>
    public BookCollection()
    {
    }

    /// <summary>
    /// Initializes a new instance of the BookCollection class.
    /// </summary>
    public BookCollection (IList<Book> initialList)
        : base(initialList)
    {
    }
}
于 2009-12-09T06:33:33.167 に答える
1

リレーショナルバックエンドを使用している場合、データレイヤーは行と列の観点から情報を格納する必要があります（必要に応じて、型指定されたDataSetを使用することもできます）。「ビジネスオブジェクト」はありません。

ビジネス層は「ビジネスオブジェクト」を使用する必要があります。BusinessObjectsプロジェクトへの参照を持つことができます。

要約すれば：

  • UIにはBusinessおよびBusinessObjectsへの参照があります
  • BusinessにはBusinessObjectsとDataへの参照があります

お役に立てれば。

于 2009-12-08T23:45:41.493 に答える
1

BusinessObjectsプロジェクト、マッピング（ORM）を格納するサーバー側、およびそれらに対するCRUD操作（およびGetAllなどの他のもの）を公開する対応するDataAccessサービスなどがあります。

于 2009-12-09T00:20:53.433 に答える
0

私の意見では、ビジネス層だけがデータアクセスオブジェクトの知識を持っている必要があります。独自のビジネスルールとロジックを適用しながらデータ操作に使用し、ダムオブジェクト（データ転送オブジェクトなど）を上のUIレイヤーに返す必要があります。

AutoMapperのようなものを使用して、データとビジネスオブジェクトの間で自動的にマッピングすることができます。

于 2009-12-08T23:57:58.307 に答える
0

モデルプロジェクトで必要なものを作成してインターフェイスし、その定義をデータレイヤーに実装することをお勧めします。そうすれば、3つ（4つ？）のプロジェクトすべてが、その実装方法を知らなくても、その定義を使用できます。

于 2009-12-08T23:51:13.857 に答える
0

それは本当にパターンに依存します。MVC（フロントコントローラーパターン）を使用している場合、モデルはアプリケーションが動作するデータのドメイン固有の表現です（通常はORMがこれを支援します）このクラスにはDATAプロジェクトを使用します。

モデルはデータアクセスオブジェクトではないため、データアクセスは別のプロジェクトのリポジトリの形式になります。ビジネスルールのサービス、そして最後にWebプロジェクト。このアプローチでは、Data.dllはすべてのプロジェクトで参照されます。モデルは遍在するようなものです。

DATA(Domain Model) -> REPOSITORY(Data Access) -> SERVICE(Business Rules) -> WEB
于 2009-12-09T00:11:00.863 に答える