在 ASP.NET 应用程序中自动生成 DAL答案

【问题标题】：Auto generating DAL in an ASP.NET application在 ASP.NET 应用程序中自动生成 DAL
【发布时间】：2010-12-10 23:48:24
【问题描述】：

给定一个存储过程，有没有办法自动生成数据访问层？我知道这可以使用 Codesmith 通过创建 cs 模板来完成，但我想知道是否有免费/付费的解决方案。

该架构的计划是：

ASP.NET 代码背后 -> 业务层 -> 数据访问层 -> 存储过程。

BL 层充当 DAL 的通道，也可以自动生成。

非常感谢任何提示/建议！

【问题讨论】：

您可以使用 ORM，有许多免费选项，但 ORM 在用于表而非存储过程时往往会提供更多价值。
如果您愿意考虑商业（非免费）选项，您认为 CodeSmith 的缺点是什么？
CodeSmith 非常棒！我想知道是否有其他工具可以帮助我抢占先机。我也倾向于 .NET 框架（或 Microsoft 的东西）的一部分，而 CS 是第 3 方工具
反对表格而不是反对 SP 是一种常见的做法吗？优缺点都有什么？谢谢
如果您使用存储过程，我可能会建议您坚持使用 CodeSmith。这听起来不像你真的想要/需要一个 ORM。存储过程与表/动态 SQL 是一个非常有争议的问题，你不会得到一个简单、明确的答案。

标签： .net asp.net stored-procedures code-generation data-access-layer

【解决方案1】：

只需使用实体框架：
http://msdn.microsoft.com/en-us/library/bb399203.aspx

【讨论】：

【解决方案2】：

当前形式的实体框架是存储过程的非首创者。要使每个存储过程正常工作，必须完成太多的手动工作。不过，我不能代表 .net 4 Entity Framework。

LINQ to SQL 对存储过程非常友好。使用 /procs 选项运行 SQLMETAL 以让它自动生成您的 DAL。

不过有两个限制：

LINQ to SQL 不会运行使用动态 SQL 的存储过程。
LINQ to SQL 也不会运行从临时表返回数据的存储过程。

显而易见的第一个原因是 LINQ to SQL 无法为这些存储过程生成必要的元数据，但存储过程中的动态 SQL 无论如何都是不好的做法。

【讨论】：

在可用的 ORM 中，LinqToSql 对存储过程有一些最好的支持。也就是说，LinqToSql 是一个功能很差的 ORM，考虑到免费提供的更好的替代方案，我不会将它推荐给大多数项目。有趣的是，您在没有严格要求时推荐 SQLMetal。

【解决方案3】：

我还不建议您使用实体框架，因为它仍然有很多怪癖。当 .NET 4.0 正式发布时，您将拥有 Entity Framework 4.0。在那个版本中，我可能会放弃 NHibernate 和 LINQ to SQL（两者的角色非常不同）而只使用 EF，因为它既有 LINQ to SQL 的易用性，又有 NH 的灵活性。

现在我建议您使用 LINQ to SQL，因为它很容易启动和运行，而且大部分时间它都能正常工作！

【讨论】：

考虑到发布这个项目的计划是在 2010 年第一季度末，并且考虑到这将是一个相当大的应用程序的框架，你建议我拿一份 VS 2010 beta 和 . NET 框架并使用 EF？
NHibernate 支持 Linq 已经有一段时间了。每个 ORM 都有“怪癖”。
@OP 鉴于 VS2010 目前定于 2010 年 3 月发布并且该日期可能会推迟，我不建议承担这种依赖关系。
正如我所说...等待正式发布！ LINQ to SQL 或 LINQ to NHibernate...Fluent NHibernate..etc.

【解决方案4】：

Linq2SQL 或 SubSonic 都适用于此目的。

编辑：Linq2Sql 应该是“死的”，但它在当前形式下仍然非常有用。我只是不会对它进行任何长期投资。

【讨论】：

关于它已死的说法在大约 6 个月前是正确的。但是，正在开发 EF 的团队也在开发 L2S，L2S 将在 .NET 4.0 版本中添加许多新功能。
@Andrew 你有该声明的来源吗？
@Amr 那篇博文没有提到 LinqToSql 申请了更多的资源来开发重要的新功能。
对于投反对票的人，有什么理由吗？对我来说似乎是一个相当无辜的评论..
@Chris，我不反对，但任何喜欢 LinqToSql 的人都有理由反对您的回答。你可以通过解释为什么你认为你的选择比其他选项更好来改进你的答案。

【解决方案5】：

实体框架的另一个投票，虽然这将取决于底层表结构，而不是存储过程。我不知道允许实体框架根据存储的过程输出确定类结构的方法。

我已经确定我们最好的方法是手动编写我们的类和 CRUD 存储过程。许多人会对该解决方案提出异议，但根据我使用任何类型的 ORM 框架的经验，都会导致 SQL 不够优化，并且受到限制，尤其是考虑到使用框架会阻塞的存储过程的能力。

陈词滥调的存在是有原因的：如果你想把它做好，那就自己做。您在应用程序中引入的第 3 方组件越多，您要求解决的不受您直接控制的问题就越多。我讨厌订阅 Not-Invented-Here 综合症，但这是我认为有效的一种情况。

【讨论】：

您尝试过哪些 ORM 没有满足您的需求？ Entity Framework 几乎不以生成高性能 SQL 的能力而闻名。

【解决方案6】：

查看这个最著名的列表ORM tools ".Net"

【讨论】：

在列表中，您推荐哪一个？
我推荐，linqtosql，llbl，subsonic。