asp.net - 架构设计 DAL 层

Question

我正在研究中型 Web 应用程序的架构，对于我的 DAL 层，我有 3 个选项

1) 传统的基于存储过程的架构(使用 Codesmith 的 NTiers 模板)

2)LINQ To SQL(或codesmith的PLINQO模板)

3)LINQ到实体

从上面的 LINQ 到实体是遥不可及的，因为我们需要非常快速地启动应用程序，而且我们没有足够的技能，而且团队从未开发过任何 OR/M 工具，这对他们来说将是陡峭的学习曲线(这是我读到的一些地方)

我更喜欢继续使用 LINQ to SQL(但唯一担心的是微软不会进一步支持或增强 LINQ to SQL)，从我的角度来看，如果微软不打算进一步增强它，我没有任何问题我在我的项目中需要的功能就足够了。

现在我的问题是我应该使用 linq to sql 还是应该坚持传统架构？

或者还有其他任何选择......

编辑:我将使用 SQL Server 作为数据库，它不需要与任何其他数据库进行交互

设计 DAL 层的最重要目标之一是更快的开发和可维护性以应对 future 的数据库表更改，因为将来该字段可能会增加或减少。

此外，如果您觉得任何 ORM 工具都非常好并且没有陡峭的学习曲线，那么我们也可以使用

请提供建议

Answer 1

由于您在中型项目中工作，因此我建议您使用 LINQ-TO-SQL，因为这些优点

使用 LINQ to SQL 的优势:

• 没有魔法字符串，就像在 SQL 查询中那样
•智能感知
• 数据库更改时编译检查
•更快的开发
•工作模式单元(上下文)
•自动生成的域对象是可用的小项目
•延迟加载。
• 学习编写 linq 查询/lambdas 是 .NET 开发人员必须学习的。
关于性能:

• 在大多数解决方案中，性能很可能不会成为问题。预先优化是一种反模式。如果您稍后发现应用程序的某些区域变慢，您可以分析这些部分，在某些情况下甚至将一些 linq 查询与存储过程或 ADO.NET 交换。
• 在很多情况下，延迟加载功能可以提高性能，或者至少可以大大简化代码。
关于调试:

• 在我看来，调试 Linq2Sql 比存储过程和 ADO.NET 容易得多。我建议你看看 Linq2Sql Debug Visualizer，它可以让你看到查询，甚至在调试时触发执行查看结果。
•您还可以配置上下文以将所有 sql 查询写入控制台窗口，更多信息请点击此处
关于另一层:

•Linq2Sql 可以看作是另一层，但它是一个纯粹的数据访问层。存储过程也是另一层代码，我见过很多将部分业务逻辑实现到存储过程中的案例。这在我看来要糟糕得多，因为您随后将业务层拆分为两个地方，开发人员将更难以清楚地了解业务领域。