Question

你可能觉得这是作业，因为我很抱歉。我搜索过但找不到合适的答案。

所以我的问题是：

我有几个类，每个类都有一个保存方法。所以我为数据库处理创建了一个单独的类。

namespace HospitalMgt.Data
{
    public static class DBConnection
    {
        public static string constr = "Data Source=ABD;Initial Catalog=HospitalMgt;User Id=sa;Password=123";
        public static SqlConnection con;
      //  public static SqlCommand com;

        public static SqlConnection OpenConnection()
        {
            con= new SqlConnection(constr);
            con.Open();
            return con;
        }

    }
}

但是，我不认为使用DBConnection类实现所有类是合适的。

我的问题：

哪种设计模式适合克服这个问题？
将DBConnection创建为类是一种好习惯吗？（或者它应该是一个接口）

我使用Factory方法找到了一些关于DA图层的文章，但据我所知，这种模式并不适合我的情况。

Answer 1

通常，如果我不能使用任何现有框架，我同时使用Repository和Active模式。

为简单起见，您只能使用Repository模式。我通常这样定义：

//  Define a generic repository interface
public interface IRepository<Key, E> where E:IEntity<Key>>{
    void Add(E entity);
    void AddRange(IEnumerable<E> entities);
    IEntity<Key> Get(Key key);
    IEnumerable<E> GetRange(IEnumerable<Key> keys);
    IEnumerable<E> GetAll();
    //  ..., Update, Delete methods
}

//  Create an abstract class that will encapsulate the generic code
public abstract class Repository<K, E> where E:IEntity<K>>:IRepository<K, E>{

    protected Repository(/*parameter you may need to implement the generic methods, like a ConnectionFactory,  table name, entity type for casts, etc */){}

    public override void Insert(IEntity<Key> entity){
        //  do the insert, treat exceptions accordingly and encapsulate them in your own and more concise Exceptions, etc
    }
    //  ...
}

//  Create the entities classes, one for each table, that will represent a row of that table
public class Car: IEntity<String>{/* Properties */}

//  Create a specific repository for each table
//  If the table have a composed key, just create a class representing it
public CarRepository: Repository<String, Car>{

    public CarRepository(){/* pass the base parameters */}

    // offer here your specific operations to this table entity
    public IEnumerable<Car> GetByOwner(PersonKey ownerKey){
        //  do stuff
    }
}

您现在有足够的工具来操作数据库，但如果需要，您可以使用活动模式。一个简单的例子：

public class Person:IEntity<PersonKey>{
    public PersonKey Key{get;}
    public IEnumerable<Car> OwnedCars{
        get{
            CarRepository rep = DBSingletons.Cars;
            return rep.GetByOwner(this.Key);
        }
        set{
            //  do stuff
        }
    }
}

显然，在进行自己的实现时，必须考虑线程安全，以便更好地使用事务，特别是跨不同的实体存储库。

//  simple example
ITransaction t = TransactionFactory.GetNewTransaction();
t.begin();
try{
    //  create person entity
    personRepository.Add(person, t);
    //  create cars assigned to person
    carRepository.AddRange(cars, t);
    t.commit();
}catch(Exception){
    t.rollback();
}

确保你真的想要创建自己的DAL，因为它可能会变得非常复杂，特别是试图开发最通用的解决方案。

Answer 2

我建议使用ORM，实体框架或NHibernate会做得很好。然后，您不必担心db上下文或创建SQL语句。

Answer 3

首先，我想向您推荐文章Design Patterns for Data Persistence by Jeremy Miller。

有一些数据访问层模式：

Active record pattern（wiki，Detailed info）。
Repository pattern（Detailed info）。

Answer 4

我建议您使用RepositoryBase进行所有这些常见操作。如果您决定使用ORM进行数据访问，最好在基于Generic Type存储库的存储库实现中进行思考。

这是一篇很好的文章：

http://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/

Answer 5

它过于陈旧但只是绕过这个问题，无法抗拒发表我的想法。

我发现Repository UnitOfWork与1有一些下降ORM是很好的方法。这最大限度地减少了大部分问题。

上面提到的UoW链接可以在Repository中注入。这增加了使用的灵活性。此外，所有数据库通信代码都集中在一个地方。该示例不完整，但是启动点。

上面链接中提到的存储库模式实际上是一个通用的基类。您可以为从中派生的每个具体存储库创建新类。

通用存储库被视为反模式;互联网上有很多文章可以解释它。

为什么通用存储库是反模式的？

存储库是正在建模的域的一部分，并且该域不是通用的。
- 并非每个实体都可以删除。
- 不是每个实体都可以添加
- 并非每个实体都有存储库。
- 查询变化很大;存储库API变得与实体本身一样唯一。
- 对于GetById()，标识符类型可能不同。
- 无法更新特定字段（DML）。
通用查询机制是ORM的责任。
- 大多数ORM都公开了一个与Generic Repository非常相似的实现。
- 存储库应该使用ORM公开的通用查询机制为实体实现SPECIFIC查询。
无法使用复合键。
无论如何它都会泄漏服务中的DAL逻辑。
- 如果您接受参数，则需要从服务层提供谓词条件。如果这是特定于ORM的类，则会将ORM泄漏到服务中。

我建议您阅读这些（2，3，4，5，{{3}}）文章，解释为什么通用存储库是一种模式。

<强>解决方案：

编写一个由具体存储库包装的抽象通用存储库。这样您就可以控制公共接口，但仍然具有来自通用存储库的代码重用的优势。
使用通用存储库但使用合成而不是继承，并且不要将其作为合同公开给域。

在任何情况下，都不要将Generic Repository暴露给调用代码。另外，不要在具体的存储库中公开IQueryable。

数据访问层的设计模式

5 个答案: