微软提供了许多不同的选项来进行数据访问。哪一种最适合可扩展的应用程序？

临q

我们应该使用Linq吗？看起来确实很容易，但是如果我们知道SQL确实有帮助的话。我也听说我们不能使用Linq在ASP.NET中运行异步查询。因此，我想知道它是否真的可扩展？是否有使用Linq的大型站点(可能有stackoverflow例外)。

实体框架

没有听到太多关于实体框架的喧闹声。似乎更接近我熟悉的对象模型。

Astoria /动态数据

我们应该将数据作为服务公开吗？

在进入NHibernate之类的其他ORM产品之前，我很困惑。任何想法或者智慧哪个更好？

解决方案

回答

我认为ADO.Net数据服务(以前称为Astoria)可以发挥巨大作用。它非常适合Web的REST样式体系结构。

由于网络是可扩展的，因此我认为遵循其架构的任何事物也都是可扩展的。
另外，我们可能想留意SQL Server数据服务。

回答

使用对我们有用的任何东西。如果我们已经有一个相当标准化的数据库(即，对主键和外键的良好定义)，则这些设置最容易设置。但是，如果我们获得的数据不容易标准化，那么Entity Framework比LINQ to SQL更灵活，但是配置起来确实需要做更多的工作。

回答

我们一直在集群环境中对LINQ进行试验，它似乎在单个计算机和整个集群上都可以很好地扩展。在我们提供的3个选项中，我想说LINQ是更好的选择，尽管每个选项的目标受众都略有不同，因此在决定访问方式之前，应先定义对数据的处理方式。

回答

如果我们在谈论关系数据库，那么我的投票就是将所有数据操作封装在存储过程中，而不管我们如何从其他层访问它们。

如果禁用所有对数据库的读/写访问(通过存储过程除外)，则可以将数据模型隐藏在定义良好的合同后面。数据模型是可以自由更改的，只是存储过程仍然可以使用它们的输入和输出。

这样，DBA便可以完全自由地调整应用程序并进行扩展。当数据库外部的工具正在生成SQL时，这是一个非常非常困难的任务。

回答

我建议使用linq。它可以在我们的网站上很好地扩展，并且使用起来非常简单。

回答

在LINQ上使用存储过程...但是不要让存储过程变成数据访问层！

回答

我会推荐NHibernate或者Entity Framework。对于大型站点，我将使用ADO.NET数据服务。我不会用LINQ to SQL做任何大事。我认为Stack Overflow可能最终会引起一些有趣的规模问题，即2层而不是3层，并且随着数据库物理方面的变化以及这些变化在整个代码中的波动，它们还会在重构时遇到一些麻烦。只是一个想法。

回答

如今，锁定存储过程似乎是一种逐渐消失的想法，至少这是我目前的观察。这种思维方式确实适合于ORM世界，因为它们通常更直接地与表对抗，但任何有价值的ORM也会允许在我们别无选择的时候使用proc。

围绕EF的观点很多，不管有人说什么好坏，它都是V1产品，并且凭经验法则，MS大约需要3转才能使其正确运行，因此，谨慎地等待下一次转至少。

在这个领域，最大的参与者似乎是NHibernate，并且在社区中对此也有很多支持。语言功能Linq在进入NHibernate堆栈时不应过分。