我希望社区对我对Linq to Sql和其他ORM映射器的一些看法有所了解.
我喜欢Linq to Sql以及在本机开发语言中表达数据访问逻辑(或一般CRUD操作)的想法,而不是必须处理C#和SQL之间的"阻抗不匹配".例如,要返回与业务层的EventDataSource兼容的Event实例列表,我们使用:
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
如果我使用旧的SQL-to-C#构造实现它,我必须创建一个Command类,添加EventID参数(使用字符串来描述"@EventID"参数),将SQL查询字符串添加到命令类,执行命令,然后使用(cast-type)nwReader ["FieldName"]拉取每个返回的字段值,并将其分配给我创建的EventData类实例的成员(yuck).
所以,这就是人们喜欢Linq/SubSonic /等的原因.并且我同意.
然而,从更大的角度来看,我看到了一些错误的东西.我的感觉是,微软也看到了一些错误,这就是为什么他们将Linq杀死为SQL并试图将人们转移到Linq to Entities.只是,我认为微软正在加倍打赌.
那么,有什么不对？
问题是有架构的宇航员,特别是在微软,他们看着Linq到Sql,并意识到它不是一个真正的数据管理工具:在C#中还有许多你不能轻易做到的事情,他们的目标是修复它. 你看到这体现在Linq to Entities背后的野心,关于Linq 的革命本质的博客文章甚至是LinqPad的挑战.
而这个问题是在于,它假定SQL的问题.也就是说,为了减轻轻微的不适(SQL和C#之间的阻抗不匹配),当创可贴(Linq to SQL或类似的东西)做得很好时,微软提出了相当于太空服(完全隔离).
据我所知,开发人员非常聪明,可以掌握关系模型,然后在开发工作中智能地应用它.事实上,我会更进一步说Linq to SQL,SubSonic等已经过于复杂:学习曲线与掌握SQL本身并没有太大的不同.因为,在可预见的未来,开发人员必须掌握SQL和关系模型,我们现在面临学习两种查询/ CRUD语言的问题.更糟糕的是,Linq通常很难测试(你没有查询窗口),从我们正在做的实际工作中删除了一层(它生成了SQL),并且对于像SQL结构这样的SQL结构具有非常笨拙的支持(最好)日期处理(例如DateDiff),"拥有"甚至"分组依据".
有什么选择？就个人而言,我不需要像Linq to Entities那样的数据访问的不同模型.我更喜欢在Visual Studio中弹出一个窗口,输入并验证我的SQL,然后按一个按钮生成或补充一个C#类来封装调用.既然你已经知道了SQL,你不想只输入这样的东西:
Select EventID, Title From Events Where Location=@Location
并最终得到一个EventData类,A)包含EventID和Title字段作为属性,B)有一个工厂方法,它将一个'Location'字符串作为参数,并生成一个List <EventData>？你必须仔细考虑对象模型(上面的例子显然没有解决这个问题),但仍然使用SQL同时消除阻抗不匹配的基本方法对我很有吸引力.
问题是:我错了吗？Microsoft是否应该重写SQL基础结构,以便您不必再学习SQL /关系数据管理？ 他们可以用这种方式重写SQL基础结构吗？或者你认为在SQL之上的一个非常薄的层来消除设置参数和访问数据字段的痛苦是足够的吗？
更新我想推广到顶部的两个链接,因为我认为它们捕获了我所追求的重要方面.首先,CodeMonkey指出了一篇题为"计算机科学的越南" …