我正在研究中型网络应用程序的架构。对于我的DAL图层，我有3个选项
1）传统的基于存储过程的架构（使用Codesmith的NTiers模板）
2）LINQ to SQL（或代码匠的PLINQO模板）
3）LINQ To Entity
从上面LINQ到Entity是遥不可及的，因为我们需要非常快速地启动应用程序而且我们没有相同的技能组，并且团队从未使用任何OR / M工具它将是陡峭的学习曲线对于他们（这是我读到的地方）
我更喜欢继续使用LINQ to SQL（但只是担心微软不会支持或进一步增强LINQ to SQL），从我的观点来看，如果微软不打算进一步增强它我没有任何我在项目中需要的功能就足够了。
现在我的问题是我应该使用linq到sql还是应该坚持使用传统架构？
或者其他任何选项都是......
编辑：我将使用SQL Server作为数据库，它不需要与任何其他数据库进行交互
设计DAL Layer的最重要目标之一是更快的开发和可维护性，以便将来更改数据库表，因为将来可能会增加或减少字段。
此外，如果你觉得任何ORM工具真的很好并且没有陡峭的学习曲线那么我们也可以使用
请提供建议
答案 0 :(得分：2)
当您在中型项目中工作时，我建议您使用LINQ-TO-SQL，因为这些优势
使用LINQ to SQL的优点：
•没有像SQL查询中那样的魔术字符串 •智能感知 •数据库更改时编译检查 •加快发展 •工作单元模式（上下文） •自动生成的域对象，它们是可用的小项目 •延迟加载。 •学习编写linq查询/ lambdas是.NET开发人员必须学习的东西。 关于表现：
•在大多数解决方案中，性能最有可能不会成为问题。预优化是一种反模式。如果您稍后看到应用程序的某些区域变慢，您可以分析这些部分，在某些情况下甚至可以使用存储过程或ADO.NET交换一些linq查询。 •在许多情况下，延迟加载功能可以加快性能，或者至少可以简化代码。 关于调试：
•在我看来，对Linq2Sql进行调试比存储过程和ADO.NET都要容易得多。我建议您查看Linq2Sql Debug Visualizer，它可以让您查看查询，甚至触发执行以在调试时查看结果。 •您还可以配置上下文以将所有sql查询写入控制台窗口，此处提供了更多信息 关于另一层：
•Linq2Sql可以看作是另一层，但它是一个纯粹的数据访问层。存储过程也是另一层代码，我已经看到很多情况，其中部分业务逻辑已经实现到存储过程中。在我看来，情况要糟糕得多，因为您将业务层拆分为两个位置，开发人员更难以清楚地了解业务领域。
答案 1 :(得分：1)
没有绝对优先编写DAL的方法。这些都是选择。选择哪一个取决于您的项目，技能和倾向。
通常，使用LINQ可以提高效率。另一方面，使用存储过程构建的DAL可以更快地执行。
只有当您需要一些默认的LINQ to SQL提供程序无法生成的特定查询时才会出现这个问题。在这种情况下，您将需要使用LINQ代码插入您需要的自定义存储过程。
关于LINQ to SQL支持和进一步开发，它已经很久以前就已经停止了。所以没有官方进一步发展。注意：对于LINQ to SQL（它将由EF接管）关系解决方案都是如此，而不是主LINQ功能。
实体框架在其第1版中仅受到了大量批评。建议你等到v2出来。
LINQ（over Entity Framework或任何其他流行的ORM）最重要的限制是它不支持1到n映射。也就是说，每个LINQ类只能映射到一个表，而不是代表其他几个类的某种视图。也许这对你来说并不重要，但也许就是这样。取决于你的项目。
答案 2 :(得分：1)
存储过程与ORM的争论是长期存在的，不太可能很快得到解决。我的建议是使用ORM（在你的情况下是Linq-to-Sql）。
是的，存储过程总是会更快，因为查询是预编译的。您必须要问自己的真正问题是，您是否拥有这样一个性能密集型系统，您的用户实际上会注意到差异。请记住，使用存储过程意味着您需要手动编写所有自己的查询，其中使用ORM为您执行此操作。这通常意味着ORM将加速您的开发。
既然你提到加快开发时间是你的目标之一，我会推荐Linq-to-Sql - 否则你基本上会自己编写整个DAL。
答案 3 :(得分：1)
您提供的所有选项都有明显的缺点。它们都不符合您的要求。
您需要优先考虑对您来说最重要的事项。
如果学习曲线是您最大的问题，如果您已经熟悉ADO.NET，DataTables等，请远离所有ORM。
如果开发速度是您最大的问题，您应该学习ORM并走这条路。最值得推荐的ORM是NHibernate。每个其他ORM都有重大缺陷。 NHibernate适用于绝大多数项目，而其他ORM在情境上更合适（取决于您的数据库设计，模型设计，敏捷性要求，遗留模式支持等）。所有ORM都有学习曲线，它们只是在不同的时间以不同的方式发挥作用。
答案 4 :(得分：0)
为了扩展@Developer Art，使用传统的存储过程方法可以将业务逻辑放在数据库中。通常你会想避免这种情况，但有时候有必要这样做。更不用说您还可以使用此方法在数据库级别强制执行约束和权限。这一切都取决于您的要求。
答案 5 :(得分：-1)
有了这些限制，我会说只是坚持adhoc /自定义查询和ADO.NET而不是任何爵士乐的东西。同样基于存储过程的DAL更快是基于概念的蹩脚参数，如存储过程是预编译的，但它们不是。他们拥有的只是查询计划缓存。因此，存储过程的投资越少，您就越好。我建议ADO.Net和从实体对象构造的自定义动态查询。