我希望社区对我对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
问题是:我错了吗？Microsoft是否应该重写SQL基础结构,以便您不必再学习SQL /关系数据管理？ 他们可以用这种方式重写SQL基础结构吗？或者你认为在SQL之上的一个非常薄的层来消除设置参数和访问数据字段的痛苦是足够的吗？
更新我想推广到顶部的两个链接,因为我认为它们捕获了我所追求的重要方面.首先,CodeMonkey指出了一篇题为"计算机科学的越南"的文章. 这需要一段时间才能开始,但这是一个非常有趣的阅读.其次,AnSGri指出Joel Spolsky的一个更突出的部分:Leaky Abstractions法则.它不完全是主题,但它很接近,是一个很好的阅读.
更新2:我给了ocdecio的"答案",尽管这里有很多很好的答案,"正确"答案的选择纯粹是主观的.在这种情况下,根据当前的技术状况,他的答案与我认为真正是最佳实践的平方.然而,这是我完全期望发展的领域,因此事情可能会发生变化.我要感谢所有贡献的人,我赞成所有我认为给出了深思熟虑的答案的人.
让我先说一下,我是一个染成羊毛的数据库人.
作为一种粗略的过度概括:开发人员不了解SQL.开发人员真的不想知道SQL.他们可以写它,他们可以设计表格,但这让他们觉得很蠢.当必要的查询不仅仅是简单的连接时,他们往往会做蠢事.不是因为开发人员是愚蠢的 - 因为他们不能被打扰.他们喜欢生活在一个他们只需要处理一个概念空间的世界; 从对象移动到桌子和后面是一个上下文切换他们不喜欢支付的价格.
这并不意味着它们是坏的,也不是错的; 这意味着有改进的机会.如果您的客户(在这种情况下,开发人员使用您的框架)不喜欢SQL和表 - 给他们一层抽象,让他们在不处理底层混乱的情况下逃脱.
这与使垃圾收集/自动内存管理成为重大打击的逻辑相同.是的,开发人员可以处理它; 是的,他们可以编写没有它的更好优化的代码; 但不必处理它会让他们更快乐,更有成效.
我认为ORM的普及是由开发人员在应用程序之后开发数据层并一遍又一遍地编写相同的CRUD代码而产生的.ORM只是另一种工具/技术,它允许开发人员花费更少的时间反复编写相同的SQL语句,并专注于应用程序的逻辑(希望如此).
至少6年来,我一直在使用自己的ORM,它基于一个非常简单的概念:投影.每个表都投影到一个类中,并根据类定义动态生成SQL.它仍然需要我知道SQL,但它负责90%简单的CRUD,我从来没有必要管理连接等 - 它适用于主要的数据库供应商.
我很满意我拥有的东西,并没有找到任何值得放弃它的东西.
恕我直言,OR/M不仅仅是"抽象SQL"或隐藏SQL,或启用多DBMS支持.
它使您可以更专注于您的问题域,因为您必须花更少的时间编写无聊的CRUD SQL查询.另一方面,如果你使用一个好的OR/M,这个OR/M应该能让你编写SQL查询,如果这似乎是必要的.
如果你正确使用它,OR/M可以是一个强大的工具; 它可以处理延迟加载,多态查询/关联...
不要误会我的意思; 纯SQL没有什么问题,但是,如果你必须自己将你的(经过深思熟虑和规范化的)关系模型转换为富有表现力的OO /域模型,那么我认为你花了很多时间来做管道工作.
使用OR/M也并不意味着您 - 作为开发人员 - 应该不了解SQL.相反的是真实的imho.
了解SQL并知道如何编写有效的SQL查询,将使您能够正确使用OR/M.
我还必须承认,我正在考虑用NHibernate写这个.这是我正在使用atm的OR/M,我没有使用Linq到SQL或Linq到实体(还).
Linq的设计和linq to entity框架肯定有用作orm工具,但最大的想法是它将被用作查询任何数据源的公共api,而不仅仅是RDBMS.
我记得读过linq,虽然显然是以SQL为设计理念,但它应该是任何数据存储的查询语言.您可以为SQL编写linq查询,但理论上您也可以编写以ldap,文件系统,交换,Web服务和无限广告为目标的linq查询.您不能将SQL用于这些程序.
您还需要为几乎每个数据存储学习不同的API.Linq为每个人提供了创建数据访问API的共同目标.
这种愿景是否有效还有待观察,但这就是主意.我认为,随着我们希望系统越来越多地互操作,我们可能会发现l2e的一些非常好的用途.
如果我能再次找到它们,我会添加一些参考文献.
http://laribee.com/blog/2007/03/17/linq-to-entities-vs-nhibernate/
我同意100%.很多这是因为程序编码技能和SQL编码技巧非常不同; 而这一事实并未得到广泛认可.因此,在该实现发生之前,程序员会搜索使其技能组从一个域转移到另一个域的方法.
它不起作用.
您只需学习如何进行相移:了解如何根据您要处理的域而不同地考虑您的代码.
有没有人注意到当查询从SQL映射到LINQ时,查询会变得多么复杂和冗长？比如,在所有在线示例中？
你应该停止担心并学会爱ORM.这些抽象将有助于我们集中技能并在该领域取得进步.
仍然有足够的空间利用您获得的功能技能并将其应用于应用程序层.事实上,这是LINQ to SQL优于其他ORM的优势之一.
我只能同意其他许多意见.您节省的时间,您可以专注于优化您的域模型,并提供更好的应用程序.而且,一旦您确定了瓶颈,就可以使用创建优化的SQL.
可能不会立即显而易见的是,ORM具有许多非常好的功能.有助于避免一遍又一遍地加载项目的身份映射,延迟加载可帮助您以较少的管道表达域,并且工作单元可帮助您跟踪更改并优化数据库写入.
正如Dmitriy 指出的那样,开发人员不了解SQL.更确切地说,大多数人都知道 SQL,但是不理解它并且肯定不喜欢,所以他们倾向于搜索魔术子弹,创造对像Linq这样的东西的需求来制造他们不喜欢的错觉(嗯,抽象)不要使用与他们心爱的班级不同的东西.
这是非常糟糕的,因为泄漏抽象的定律总是成立.
一些ORM解决方案确实很好(例如JPA/Hibernate),不是因为使用它们就不必担心SQL.事实上,要有效地使用JPA,您需要对DB进行非常深入的了解,特别是查询能力.好处是它们使机器完成无聊的工作,直到从头开始自动生成整个数据库.
我认为Linq to SQL并不能解决实际问题.这是其他演示文稿,仅此而已.它可能是好的,虽然它使已经很复杂的语言过于复杂.另一方面,Linq to Objects是一个非常有趣的概念,因为它是一种sql-querying集合.
历史的角度.
当Codd等.人.最初正在制定关系数据库的理论和实现,一个完全独立的问题是"我们如何查询这些东西"？提出了许多策略和语法,具有各种优点和缺点.其中一个候选者是SQL(显然是最早的形式).另一个是QBE(按示例查询).另一个被称为"quel",我相信; 还有其他几个.SQL肯定没有占据主导地位,因为它被誉为优于其他所有人.然而,不幸的是,其他人几乎已经消失,导致我们所有人的贫困(因为他们可以同时使用相同的数据.)
如果微软有一个很好的故事,他们正在复兴这些其他语言之一,或者发明了一个有价值的补充,那么我认为我们建议听听.但到目前为止,我所看到的只是另一个"一环统治所有".
SQL背后有很多思想和严谨,还有很多久经考验的耐用性.微软有一定的历史,相信他们公认的顶级开发组织可以超越我们其他人,包括我们的集体机构记忆.这种方式似乎并不常见.只要我们与关系数据存储绑定在一起,我们就应该三思而后行的超集抽象范例,这些范式将我们从具有相同或更好性能的承诺转移到裸机上.
作为一个ORM项目的作者,我不得不承认,我对这样一个问题的回答往往有点偏颇.在阅读问题之前,我已经对答案做了一些自己的想法,所以我已经有点固定了.
我会说我开发ORM的原因不是因为SQL和命令式编程之间的"阻抗不匹配",而是仅仅是为了成为数据库平台不可知的目的.如果您只与一个数据库供应商合作,那么必须编写更多代码来管理持久性的前一个问题是一个很小的障碍.成为数据库平台不可知是一个更具挑战性的问题,imo对您的业务的盈利能力有更大的影响,假设像我一样,您计划向其他人销售软件(并且不仅仅是在内部使用它).
几年前,当我开始使用我的ORM工具时,这个概念在我的首选语言中是不切实际的,我交谈的大多数人都不理解我为什么要这么做,社区中一些受到尊重的声音和书面文章一样多.在贸易杂志上说,我已经做过的事情不仅是不可能的,而且是不可取的.给出了一些相同的原因 - 它太复杂了,它的限制并增加了开销.今天,同一社区至少有三种流行的数据库抽象工具(虽然对ORM一词的定义存在争议).我之所以提到这一点,是因为当我开始研究这些工具时,最初的反对意见比现在更加重要.在这些年中,硬件和软件的基础技术已发生变化,从长远来看,这些工具更加实用.我倾向于尝试对软件进行长期观察并研究可能不太实用的解决方案,但这些解决方案很快就会变得实用.因此,我不会将LINQ to Entities视为某些问题的良好解决方案.
我也倾向于选择更多选择而不是更少.因此,虽然我可能支持开发LINQ to Entities背后的想法,但我不太愿意支持将LINQ to SQL单独删除,因为LINQ to Entities已经可用.对象非常适合做对象所做的事情,毫无疑问......在我的(有偏见的)观点中,一个问题出现在人们看到任何给定的工具或软件范例作为"魔术子弹"并且想要坚持一切必须那样.众所周知,关系数据库非常擅长处理某些其他任务,报告就是一个很好的例子.因此,在我看来,这是一种自我约束,坚持认为一切都必须是实体,因为那时你迫使自己使用低效的工具来完成工作.所以关于报道,特别是抽象反转反模式.
所以我想我的答案的概要是这样的:如果你的问题是指甲,请使用锤子 - 如果你的问题是螺丝,请使用螺丝刀.
Dmitry声明开发人员不喜欢SQL可能有很多道理,但解决方案不仅仅是ORM.解决方案是聘请开发DBA作为开发团队的一部分.在我的公司,我的.net开发团队有一个优秀的Oracle DBA,他绝对没有生产dba工作.他在我们团队中的角色是数据建模,物理数据库设计,创建存储过程,数据分析等.他是我们的数据库方面如此干净和执行的原因.我们所有的数据库访问都是通过存储过程.
什么是开发DBA？ http://www.simple-talk.com/sql/database-administration/what-use-is-a-development-dba/
京公网安备 11010802040832号 | 京ICP备19059560号-6 