1

現在、新しいアプリケーション用にデータアクセス層とビジネスロジック層のクラスを構築していますが、質問があります（明らかに）。まず、役立つ可能性のある詳細を次に示します。

  • モデルクラスとデータアクセスにEntityFramework5を使用する
  • 各「レイヤー」は、異なるクラスライブラリと名前空間（つまり、App.Model、App.DAL、App.BLL）で区切られています。

DALから始める-すべてのDALクラスが継承する基本クラスを作成することにしました。

public abstract class DALBase<T> : IDisposable
{
    protected AppEntities context;
    protected DbSet set;

    public DALBase()
    {
        context = new OECCORPEntities();
        set = context.Set(typeof(T));
    }

    protected virtual void Save()
    {
        context.SaveChanges();
    }

    public virtual void Add(T model)
    {
        set.Add(model);
        Save();
    }

    public virtual T Get(int id)
    {
        return (T)set.Find(id);
    }

    public virtual List<T> GetAll()
    {
        return set.OfType<T>().ToList();
    }

    public virtual void Delete(int id)
    {
        T obj = Get(id);
        set.Remove(obj);
        Save();
    }

    public virtual void Update()
    {
        Save();
    }

    public void Dispose()
    {
        context.Dispose();
    }
}

ご覧のとおり、基本クラスはジェネリック型を実装します。これは、DALクラスが処理するモデルの型である必要があります。ジェネリック型を使用して、コンストラクターでジェネリック引数の型を使用してDbSetを作成します。これは、以下の事前定義されたCRUDのような仮想関数（add、getなど）で使用されます。

そして、私はアイデアを思いつきました-ちょっと待ってください...それは一般的であるため、すべてのモデルにDALクラスを実装する必要はありません。私はこのようなものを書くことができます：

public class GenericDAL<T> : DALBase<T>
{
    public GenericDAL() : base() {}
}

...どのモデルにも使用できます。OK、ビジネスロジックレイヤーへと続きます。BLLの基本クラスも作成しました。

public abstract class BLLBase<T>
{
    protected GenericDAL<T> dal;

    public BLLBase()
    {
        dal = new GenericDAL<T>();
    }

    public virtual void Add(T model)
    {
        dal.Add(model);
    }

    public virtual T Get(int id)
    {
        return dal.Get(id);
    }

    public virtual List<T> GetAll()
    {
        return dal.GetAll();
    }

    public virtual void Delete(int id)
    {
        dal.Delete(id);
    }

    public virtual void Update()
    {
        dal.Update();
    }
}

...GenericDALを使用して作業を行います。したがって、同様の方法で、次のようなGenericBLLクラスを作成しました。

public class GenericBLL<T> : BLLBase<T>
{
    public GenericBLL() : base() { }
}

そしてそれをテストするために、単純なコンソールアプリケーション：

class Program
{
    static void Main(string[] args)
    {
        GenericBLL<ADMIN> bll = new GenericBLL<ADMIN>();
        List<ADMIN> admins = bll.GetAll();
    }
}

...ここで、「ADMIN」はモデルタイプです。チャームのように機能します。

この背後にある考え方は、追加の機能が必要でない限り、すべてのモデルに対してDAL/BLLクラスを作成する必要がないようにすることでした。なぜ私がこのようにしたくないのか誰かに教えてもらえますか？一般的なDAL/BLLクラスは仕事を成し遂げ、開発時間を節約できると思います。

お時間をいただきありがとうございます。

4

2 に答える 2

1

欠点の1つは、後でビジネスルールを追加する場合は、タイプをGenericBLL[Whatever]からWhateverBLLに切り替える必要があることです。

これに対する明らかな解決策は、GenericBLL[Whatever]から継承するクラスを作成することです。好き：

public class WhateverBLL : GenericBLL<Whatever>

代わりにこのクラスを使用してください。

于 2013-02-21T15:29:04.993 に答える
0

現在、BLLは特に付加価値を付けていません。すべての呼び出しは、単に別のレイヤーへのパススルーです。多分それはあなたのアプリケーションの単純さです（そしてあなたがとても幸運であるあなたの幸運な星に感謝します）、あるいはあなたは私が他の場所に住んでいる実際のビジネスロジックとして分類するものを持っているかもしれません。

私にとってのビジネスロジックは、データを永続化するまでに行われるすべてのこと、データを取得した後に行われるすべてのことなどです。決定、道路の分岐点、実行されるアクション。実際にデータを保存および取得することは、比較すると非常に簡単です。

したがって、一般的なDAL基本クラスを見ると、良いスタートだと思います。テスト時に置き換えることができるように、おそらくそこからインターフェイスを抽出します。今のところ、ベースを継承するクラスは値を追加していません。単にそれのためにレイヤーやクラスを作成するのではなく、それが価値を付加し、何らかの方法であなたの生活を楽にすることを確認してください。

一般的なBLLクラスを見ると、実際のビジネスロジックは、何らかの形式のコードビハインド、またはコンソールアプリのクラスファイル内に隠れていると思います。タイプによってのみ異なる一般的に適用可能な機能が存在する可能性は確かにありますが、 1つのクラスが目的の場所であるとは思いません。ここでの私の提案は、実際のビジネスロジックとは何かを再考することです。DALへの単純なパススルーレイヤーはおそらくそうではありません。

于 2013-02-21T15:44:19.247 に答える