实体框架,Dapper和SSDT的组合？

Question

我正处于建立新开发项目的早期阶段,我不确定如何设置我的数据库访问策略.我将使用Visual Studio 2012,我将针对.NET 4.5和SQL Server 2008或2012.

我不确定的是,是否使用实体框架,如果使用,在何种程度上.从数据库读取数据然后处理它将是此应用程序的主要工作,查询性能将是重要的.我知道EF5在这方面要比EF4.x好很多,但它并不是我最担心的固有EF开销(尽管像Dapper这样的东西仍然至少快两倍),但更多的是它为你提供的懒惰作为开发人员,因为通过LINQ查询太多了.所以我希望纯SQL查询成为获取数据的主要方式.

但是,我最想念EF的是:

1. 编译时间查询检查.
2. 跟踪变化.
3. 代码第一次开发.
4. 工作单元模式.

我可以在没有变更跟踪的情况下生活,通常不难确定新的或更新的内容.

我真正想要的是这个项目的开发人员不必与表设计师混在一起,但他们可以简单地编写POCO.所以,为此,我非常感谢EF的代码第一种方法.有了这个,开发人员可以克隆源代码,调用update-database并拥有一个有效的本地数据库.这对我来说过去很有用.

另一件对我来说非常重要的事情是工作单元模式,或者插入和更新的原子性.我想排队所有的变化,并在我打电话的地方有一个点SaveChanges.对于像这样的库DapperExtensions,你会得到一个Insert方法,但它会立即进行数据库调用.你可以通过在它周围包装一个事务来使它成为原子,但这与排队它不一样.所以我必须为此自己推出某种排队机制.

对于编译时查询检查,我考虑使用SQL Server数据工具(SSDT).查询将是存储过程(以避免C#代码中的大查询字符串blob)并使用SSDT这些可以在构建时检查.SSDT的另一个优点是您可以将存储过程从Visual Studio部署到目标数据库.最重要的是,这些SQL脚本将存在于源代码控制中.

因此,我的解决方案基本上由三种数据访问技术组成:

实体框架

• 将负责从POCO数据模型创建数据库.
• 将用于通过其工作单元模式插入/更新数据.需要注意的是,您首先要将Attach通过SQL获取的实体添加到上下文中.

SSDT

• 将用于在编译时验证SQL脚本.
• 允许脚本存在于Git中.
• 将部署EF无法部署到您的数据库的东西.

小巧玲珑/其他微型ORM

• 将用于获取数据

我不禁觉得这是一个弗兰肯斯坦解决方案,我使用各种各样的零碎.我还不确定SSDT和EF会以一种很好的方式协同工作.这个快速示例似乎工作正常:

// Combo of Dapper, EF and a stored proc that was published through SSDT
static void Main(string[] args)
{
  var connectionString = ConfigurationManager
    .ConnectionStrings["DbDataContext"].ConnectionString;

  using (var conn = new SqlConnection(connectionString))
  using (var ctx = new DbDataContext())
  {
    conn.Open();

    var product = conn.Query<Product>("GetProduct", 
      commandType: CommandType.StoredProcedure).First();

    ctx.Products.Attach(product);

    var order = new Order
    {
      Product = product
    };

    ctx.Orders.Add(order);

    ctx.SaveChanges();

  }
}

这种方法似乎可行,但它也很混乱.但是,如果我放弃SSDT,我将错过编译时检查SQL,如果我放弃实体框架,我将错过代码优先和更容易插入,如果我放弃直接SQL我会想念表现出很大一部分.

我有一个替代方案吗？如果没有,这里最好的方法是什么？