Общие классы DAL/BLL

Question

В настоящее время я создаю классы доступа к данным и классы бизнес-логики для нашего нового приложения, и у меня есть вопрос (очевидно). Во-первых, здесь некоторые детали, которые могут помочь:

• Использование Entity Framework 5 классов модели и доступа к данным
• Каждый «слой» отстоит в различных библиотеках и пространствах имен классов (т.е. 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() {} 
} 

... что я могу использовать для любой из моделей. ОК, и так далее на бизнес-логическом уровне. Я создал базовый класс для 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 выполнили бы свою работу, а также экономят время разработки.

Спасибо за ваше время.

Answer 1

Ну, один недостаток заключается в том, что если вы решили добавить некоторые бизнес-правила, в дальнейшем вам придется переключить тип из GenericBLL [Whatever] к WhateverBLL.

Очевидным решением для этого является создание класса, который наследуется от GenericBLL [Whatever]. Например:

public class WhateverBLL : GenericBLL<Whatever> 

и используйте этот класс вместо этого.

Answer 2

Прямо сейчас, ваш BLL не особенно повышает ценность. Каждый вызов - это просто переход к другому слою. Может быть, это простота вашего приложения (и спасибо вашим счастливым звездам, что вам так повезло), или, может быть, у вас есть то, что я буду классифицировать как реальную бизнес-логику, живущую в другом месте.

Бизнес-логика для меня - это все, что сделано до точки сохранения данных, всего, что сделано после извлечения данных, и тому подобное. Решения, вилки на дороге, действия, которые предпринимаются. Фактически сохранение и получение данных типично чрезвычайно тривиально по сравнению.

Так как я смотрю на ваш общий базовый класс DAL, я думаю, что это прекрасное начало. Я бы, вероятно, извлек из него интерфейс, чтобы заменить его при тестировании. На данный момент ваш класс, который наследует, база не добавляет значения. Не создавайте слои и классы просто ради этого, убедитесь, что он добавляет ценность и делает вашу жизнь проще.

Поскольку я смотрю на ваш общий класс BLL, я думаю, что у вас, вероятно, есть реальная бизнес-логика , спрятанная в коде в какой-либо форме или внутри файла класса в консольном приложении. Хотя, конечно, возможно, что может быть универсальная применимая функциональность, которая зависит только от типа, я не думаю, что один класс - это то, где вы хотите быть. Мое предложение здесь - пересмотреть то, что вы считаете своей фактической бизнес-логикой. Простой проходной слой к DAL, вероятно, не так.