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的简单传递层可能不是它。

通用DAL / BLL类

2 个答案: