4

EF を使用してデータ アクセスを処理する小さな個人プロジェクトを作成しようとしています。私のプロジェクト アーキテクチャには、UI レイヤー、サービス レイヤー、ビジネス レイヤー、およびデータ アクセス レイヤーがあります。EF は DAL 内に含まれています。UIからDALを参照するのは正しくないと思います。そのため、すべてのレイヤーで共有される「ビジネス オブジェクト」のカスタム クラスを作成したいと考えています。

例: User テーブルがあります。EF は User エンティティを作成します。おそらくGetListOfUsers（）へのメソッドがあります。プレゼンテーションでは、UI に DAL への直接リンクがあるため、リストで返信しないでください。おそらく次のようなメソッドを DAL で公開する必要があります。

List<MyUserObject> GetListOfUsers();

次に、ユーザー エンティティのリストを返す GetListOfUsers という内部メソッドを呼び出し、それらを MyUserObejcts に変換し、レイヤーを介して UI に戻します。

それは正しい設計ですか？私は、UI やビジネス レイヤーにエンティティ フレームワークに関する知識が必要だとは思いません。

しかし、これが意味することは、DAL とビジネス レイヤーの間にエンティティをカスタム オブジェクトに変換する「変換レイヤー」が必要なのでしょうか?

編集：

これが私がやっていることの例です:

Entity Framework を含むデータ アクセス プロジェクトがあります。このプロジェクトでは、状態のリストを取得するメソッドを用意します。

public class DataAccessor
{
    taskerEntities te = new taskerEntities();

    public List<StateObject> GetStates()
    {
        var transformer = new Transformer();
        var items =   (from s in te.r_state select s).ToList();
        var states = new List<StateObject>();
        foreach (var rState in items)
        {
            var s = transformer.State(rState);
            states.Add(s);
        }
        return states;
    }

}

私の UI/ビジネス/サービス プロジェクトは、エンティティ フレームワーク オブジェクトについて認識してはなりません。代わりに、カスタム ビルドの State オブジェクトを認識している必要があります。したがって、カスタム ビルド オブジェクトを含む共有ライブラリ プロジェクトがあります。

namespace SharedLib
{

    public class StateObject
    {
        public int stateId { get; set; }
        public string description { get; set; }
        public Boolean isDefault { get; set; }
    }


}

したがって、私の DAL は項目を Entity オブジェクトのリストに取得し、それらを変換メソッドに渡して、それらをカスタム buily オブジェクトにします。変換は EF オブジェクトを受け取り、カスタム オブジェクトを出力します。

public  class Transformer
    {
        public StateObject State (r_state state)
        {
            var s = new StateObject
                        {
                            description = state.description, 
                            isDefault = state.is_default, 
                            stateId = state.state_id
                        };

            return s;
        }
    }

これはうまくいくようです。しかし、それは有効なパターンですか？

4

2 に答える 2

2

そのため、ある時点で、UI は、所有しているデータとビジネス オブジェクトを操作する必要があります。それは人生の事実です。さらに抽象化を試みることもできますが、それは相互作用が他の場所で延期されている場合にのみ成功します。

ビジネス プロセスは UI から独立している必要があることに同意します。また、UI がデータへのアクセス方法に直接作用してはならないことに同意します。あなたが提案したもの（「GetListOfUsers（）」の行に沿ったもの）は、リポジトリパターンとして知られています。

リポジトリ パターンの目的は次のとおりです。

データを取得してエンティティ モデルにマップするロジックを、モデルに作用するビジネス ロジックから分離します。ビジネス ロジックは、データ ソース層を構成するデータの種類にとらわれない必要があります。

私のお勧めは、Repository パターンを使用してデータへのアクセス方法を非表示にし (そして、懸念事項をより適切に分離できるようにすることです)、「ユーザーのリストが必要なだけ」または「必要なだけ」という事実だけに注意することです。すべてのタイムシートの合計を計算する」など、アプリケーションに実際に焦点を当てたいものは何でも。詳細な説明については、リンクを参照してください。

于 2012-08-18T20:11:50.693 に答える
1

まず、あなたの「小さな個人的なプロジェクト」に、そのすべてのレイヤーが本当に必要ですか? 第二に、提案されたアーキテクチャは少し不明確だと思います。

私の理解が正しければ、あなたは と を分離したいと考えてUIいますDAL。そのために、たとえば、MyUserObject(明らかに定義されているDAL) クラスのインターフェイスを抽出し、それを呼び出してIMyUserObject、UI から DAL を参照する代わりに、すべての型がデータに依存しない抽象プロジェクトを参照できます。また、プレゼンテーション層 ( UI) に具体的なオブジェクトを提供するサービス層を用意することをお勧めします。MVC を利用すると、コントローラー クラスからサービスへのリンクを作成できます。サービスレイヤーは、リポジトリまたはその他の手法を使用して DAL を処理できます (選択した複雑さによって異なります)。

変換レイヤーを考慮すると、DB と通信するための単純なモデル (DTO) が 1 つ、ビジネス ロジックのすべての微妙な部分を処理する別のモデル (ドメイン モデル)、および別のモデル (プレゼンテーション) がある場合に、あるタイプから別のタイプへのマッピングを扱うと思います。ユーザーが操作できるようにするのに最適なモデルです。このような階層化により、懸念事項が適切に分離され、各タスクが単純化されますが、アプリは一般的に複雑になります。したがって、 、 、およびそれらの間のマッピングまたは変換が終了する可能性がMyUserObjectDTOありMyUserObjectますMyUserObjectView。

于 2012-08-18T20:15:41.923 に答える