数据访问层设计模式

我推荐Martin Fowler的企业应用程序架构模式。

website

这个 DataMapper 模式也是相关的。

我喜欢使用基于接口的数据库访问。Ado.net的每个db提供程序都实现基本接口,使用这些接口时,代码可能如下所示:

public static IDbConnection GetConnection(string connectionName)
{
  ConnectionStringSettings ConnectString = ConfigurationManager.ConnectionStrings[connectionName];
  DbProviderFactory Factory = DbProviderFactories.GetFactory(ConnectString.ProviderName);
  IDbConnection Connection = Factory.CreateConnection();
  Connection.ConnectionString = ConnectString.ConnectionString;
  return Connection;
}

然后,当您需要与db通信时:

public static DataTable Dummy()
{
  using (IDbConnection Connection = GetConnection("SiteSqlServer"))
  {
    IDbCommand Command = Connection.CreateCommand();
    Command.CommandText = "DummyCommand";
    Command.CommandType = CommandType.StoredProcedure;

    Connection.Open();

    using (IDataReader reader = Command.ExecuteReader())
    {
      DataTable Result = new DataTable();
      Result.Load(reader);
      return Result;
    }
  }
}

使用此技术,您可以创建完全独立于db的DAL。当然,对于一些复杂的场景来说,这还不够。但大多数情况下,这将完成工作,并且您不需要各种外部LIB。

LLBLGen. 使用适配器模型,您可以在使用相同业务对象的同时在数据提供程序之间切换。它可以为MySql和Sql Server生成代码。

Patterns of Enterprise Application Architecture .

更具体地说,我始终建议您将数据访问层隐藏在接口后面,并在运行时使用依赖项注入将特定的数据访问组件注入域逻辑。

您可以使用依赖项注入容器或 do it manually .

在技术方面,我推荐微软的 Entity Framework ,因为您的数据访问需求似乎局限于关系数据库。实体框架是微软的官方OR/M,它提供了许多不同的RDBMS以及LINQ支持。

这实际上取决于你的图层大小和你开发的产品类型。如果它包含得相当好,那么ADO.NET可能是理想的。如果它是一个更大的DAL层,并且是多目标dbms的新开发,那么最好使用ORM工具。它们是快速、高效和成熟的产品,只需更改一个参数,即可快速将目标重新定位到另一个db。编写静态ADO,是一种正在传递到遗留的东西。

有几种ORM工具可以完成这项工作,它们的工作方式略有不同,并且依赖于 根据您的预算、团队规模等,他们可以通过编写NHibernate之类的映射类来工作,也可以通过反射(即属性标记)来工作。

如果你有一些预算,那么LLBLGen是理想的。它是强类型的,还支持存储过程。

如果已经有一些数据模型可用,那么TierDeveloper是理想的。它基本上是免费的,并且通过从数据库模型开发一组类来工作。唯一的缺点是mysql的映射器是第三方的。这是一个企业级产品,免费支持ncache,也是一种可能的方法。

如果你不顾一切地坚持使用MS,他们正在转向ORM,并且有一个叫做ADO.NET实体框架的产品。从功能上讲,它不如上面定义的工具那么完整。它的成熟度大约落后3代。它在VS2008SP1中可用。mysql的连接器将是一项成本。

理想情况下,您的最佳选择是使用ORM。如果你不能支持开源,又没有预算,

希望有帮助。

我找到了 ADO.NET 这是非常有用的。它具有创建独立于所用数据库的数据访问层所需的所有功能。

NHibernate 如果你愿意学习的话,它可以处理这种情况