学习LinqToSql还是坚持使用ADO.NET？

Question

我正在讨论即将推出的ASP.NET项目使用什么技术.

假设:

• 我将使用Visual Studio 2008 SP1(.NET Framework 3.5)
• 后端将是SQL Server 2005数据库(或可能是2008)
• 代码将用C#编写
• 我已经有了LinqToObjects和LinqToXml的经验
• 我也有使用ADO.NET和一些已经构建的库的经验
• 该项目相对较小
• 该网站将以五个屏幕为特色
• 数据库可能有六到七个表
• 可能会有25-50个活跃用户
• 每天的交易量可能约为5-10个
• 将存储最少的个人数据
• 失败或网站遭到黑客攻击的后果将是微不足道的

选项:

1. 编写存储过程并使用ADO.NET调用它们.一旦我完成填充,我仍然可以使用LinqToObjects DataSet.

2. 利用我所知道的Linq已经学习LinqToSql.

分析:

我已经知道如何做选项1,但我真的很想使用Linq.选项2的问题在于,根据我读过的所有内容,LinqToSql可能会被弃用,而不是实体框架.

问题:

1. 如果您已熟悉其他Linq技术,LinqToSql的学习曲线有多陡峭？

2. 是否值得投资任何时间学习LinqToSql,因为它可能不会被微软进一步开发？

3. 理解LinqToSql会帮助我有一天理解实体框架还是他们太不同了？

4. 最终,您会针对我的情况推荐哪种方案？

更新:

我不希望这个迷路的评论:marc_s指出,LinqToSql 被正在进一步发展,至少作为.NET 4.0.链接:http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40.

我不知道这是否意味着LinqToSql毕竟有一个未来,但它确实让学习这项技术更具吸引力.

有一点我在原帖中没有提出但应该有:实体框架中的缺陷是否可能影响这个项目？

谢谢你到目前为止的答案.

更深入的分析

以下是一些LinqToSql缺点列表,基于以下一些评论:

1. 在对基础数据库进行更改时,必须不断更新设计器中的表和项.无法"刷新"或"同步"它以便自动识别更改.
2. 由于设计人员不以一致的顺序生成底层文件,因此版本控制变得复杂.
3. LinqToSql设计器生成的代码与SqlMetal不同.
4. 存在涉及急切加载的问题/错误.

其中,第1项是我最关心的问题.即使是一个小项目,变革也是不可避免的.我记得曾经尝试使用Windows窗体设计器映射到数据库,并且它在我的脸上爆炸了很多次,我放弃了它,转而支持滚动我自己的ADO.NET辅助类.

但是,看起来SqlMetal似乎能够完美地满足我的需求.我运行一个命令,它从头开始从数据库中重新生成所有内容,我已经完成了.如果我保持我的数据库简单(只是表 - 没有存储过程,视图或函数),也许我只需要SqlMetal.

Answer 1

如果您已经知道LINQ to Xml或对象(Linq"对象"只是"列表"),LINQ to Sql非常简单...

Linq To Sql并未被微软弃用,他们只是建议使用EF.它不会升级.

可以看到Linq To Sql与EF几乎相似.使用EF你可以做更复杂的事情,但在基本级别几乎相同(对于你的网站有7个表,它没有任何区别).

根据您的情况,我建议使用LINQ.它比SP + ADO.NET更有趣,更快捷.如今使用ORM几乎是一个不错的选择.不使用它应该是例外(对我来说).

Answer 2

我同意Davide Vosti,但你可能想考虑其他选项,比如NHibernate(也有LINQ支持).

EF的当前版本并不令人印象深刻 - 它创建了一些非常讨厌的T-SQL,需要很长时间才能执行.

我们目前正在使用EF,但这是我最后一次选择EF for .NET 3.5.我在.NET 4中再给它一次机会,但除非它有显着改进,否则我会选择其他选项(并且LINQ to SQL不太可能是其中之一).