Linq to SQL 是不是没有抓住重点?ORM 映射器(SubSonic 等)不是次优解决方案吗? [英] Doesn't Linq to SQL miss the point? Aren't ORM-mappers (SubSonic, etc.) sub-optimal solutions?
问题描述
我希望社区就我对 Linq to Sql 和其他 ORM 映射器的一些想法发表意见.
I'd like the community's take on some thoughts I've had about Linq to Sql and other ORM mappers.
我喜欢 Linq to Sql 以及用您的原生开发语言表达数据访问逻辑(或一般的 CRUD 操作)的想法，而不必处理 C# 和 SQL 之间的阻抗不匹配".例如，要为业务层返回与 ObjectDataSource 兼容的 Event 实例列表，我们使用:
I like Linq to Sql and the idea of expressing data access logic (or CRUD operations in general) in your native development tongue rather than having to deal with the "impedance mismatch" between C# and SQL. For example, to return an ObjectDataSource-compatible list of Event instances for a business layer, we use:
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
如果我要使用旧的 SQL-to-C# 构造来实现这一点，我必须创建一个 Command 类，添加 EventID 参数(使用字符串来描述@EventID"参数)，添加 SQL 查询字符串到 Command 类，执行命令，然后使用 (cast-type)nwReader["FieldName"] 拉取每个返回的字段值并将其分配给我的 EventData 类的新创建实例的成员(糟糕).
If I were to implement this using old SQL-to-C# constructs, I'd have to create a Command class, add the EventID parameter (using a string to describe the "@EventID" argument), add the SQL query string to the Command class, execute the command, and then use (cast-type)nwReader["FieldName"] to pull each returned field value and assign it to a member of a newly created instance of my EventData class (yuck).
所以，那就是人们喜欢 Linq/SubSonic/等的原因.我同意.
So, that is why people like Linq/SubSonic/etc. and I agree.
然而，从更大的角度来看，我发现很多事情是错误的.我的感觉是微软也看到了一些错误，这就是为什么他们 杀死 Linq to SQL 并试图将人们转移到 Linq to Entities.只是，我认为微软正在在一个糟糕的赌注上加倍下注.
However, in the bigger picture I see a number of things that are wrong. My sense is that Microsoft also sees something wrong and that is why they are killing Linq to SQL and trying to move people to Linq to Entities. Only, I think that Microsoft is doubling-down on a bad bet.
那么，怎么了?
问题是有建筑宇航员，尤其是在微软，他们看Linq to Sql 并意识到它不是一个真正的数据管理工具:在 C# 中仍然有很多事情你不能轻松轻松地完成，他们的目标是修复它.你看到这体现在背后的野心上Linq to Entities，关于革命性性质的博客文章Linq 甚至 LinqPad 挑战.
The problem is that there are architecture astronauts, especially at Microsoft, who look at Linq to Sql and realize that it is not a true data management tool: there are still many things you cannot do easily of comfortably in C# and they aim to fix it. You see this manifested in the ambitions behind Linq to Entities, blog posts about the revolutionary nature of Linq and even the LinqPad challenge.
那个的问题在于它假设 SQL 是问题所在.也就是说，为了减少轻微的不适(SQL 和 C# 之间的阻抗不匹配)，当创可贴(Linq to SQL 或类似的东西)可以正常工作时，Microsoft 提出了相当于宇航服(完全隔离)的方案.
And the problem with that is that it assumes that SQL is the problem. That is, in order to reduce a mild discomfort (impedance mismatch between SQL and C#), Microsoft has proposed the equivalent of a space suit (full isolation) when a band-aid (Linq to SQL or something similar) would do just fine.
据我所知，开发人员非常聪明，可以掌握关系模型，然后将其巧妙地应用到他们的开发工作中.事实上，我会更进一步说，Linq to SQL、SubSonic 等已经太复杂了:学习曲线与掌握 SQL 本身没有太大区别.由于在可预见的未来，开发人员必须掌握 SQL 和关系模型，我们现在面临学习两种查询/CRUD 语言的问题.更糟糕的是，Linq 通常难以测试(您没有查询窗口)，将我们从我们正在做的实际工作中移除一层(它生成 SQL)，并且对 SQL 结构的支持(充其量)非常笨拙，例如日期处理(例如 DateDiff)、拥有"甚至分组依据".
As far as I can see, developers are quite smart enough to master the relational model and then apply it intelligently in their development efforts. In fact, I would go one further and say that Linq to SQL, SubSonic, etc. are already too complex: the learning curve isn't that much different from mastering SQL itself. Since, for the foreseeable future, developers must master SQL and the relational model, we're now faced with learning two query / CRUD languages. Worse yet, Linq is often difficult to test (you don't have a query window), removes us one layer from the real work we are doing (it generates SQL), and has very clumsy support (at best) for SQL constructs like Date handling (e.g. DateDiff), "Having" and even "Group By".
什么是替代方案?就个人而言，我不需要像 Linq to Entities 这样的数据访问模型.我更喜欢在 Visual Studio 中简单地弹出一个窗口，输入并验证我的 SQL，然后按一个按钮来生成或补充一个 C# 类来封装调用.既然您已经了解 SQL，您是否更愿意输入如下内容:
What is the alternative? Personally, I don't need a different model for data access like Linq to Entities. I'd prefer to simply pop up a window in Visual Studio, enter and validate my SQL, and then press a button to generate or supplement a C# class to encapsulate the call. Since you already know SQL, wouldn't you prefer to just enter something like this:
Select EventID, Title From Events Where Location=@Location
并最终得到一个 EventData 类，该类 A) 包含 EventID 和 Title 字段作为属性，B) 有一个工厂方法，该方法将Location"字符串作为参数并生成 List
and end up with an EventData class that A) contains the EventID and Title fields as properties and B) has a factory method that takes a 'Location' string as an argument and that generates a List<EventData>? You'd have to think carefully about the object model (the above example obviously doesn't deal with that) but the fundamental approach of still using SQL while eliminating the impedance mismatch appeals to me a great deal.
问题是:我错了吗?Microsoft 是否应该重写 SQL 基础架构，以便您不再需要学习 SQL/关系数据管理?他们可以以这种方式重写 SQL 基础架构吗?或者你认为在 SQL 之上加一个很薄的层来消除设置参数和访问数据字段的痛苦就足够了吗?
The question is: am I wrong? Should Microsoft rewrite the SQL infrastructure so that you don't have to learn SQL / relational data management any more? Can they rewrite the SQL infrastructure in this way? Or do you think that a very thin layer on top of SQL to eliminate the pain of setting up parameters and accessing data fields is quite sufficient?
更新 我想将两个链接提升到顶部，因为我认为它们抓住了我所追求的重要方面.首先，CodeMonkey 指出一篇题为 "The Vietnam计算机科学." 入门需要一段时间，但非常有趣.其次，AnSGri 指出了乔尔·斯波尔斯基 (Joel Spolsky) 更突出的作品之一:抽象抽象法则.它不完全是主题，但很接近并且非常适合阅读.
Update I wanted to promote two links to the top because I think that they capture important aspects of what I am after. First, CodeMonkey points out an article entitled "The Vietnam of Computer Science." It takes a while to get started but is a very interesting read. Second, AnSGri points to one of Joel Spolsky's more prominent pieces: The Law of Leaky Abstractions. It isn't exactly on topic but it is close and is a great read.
更新 2:我已经给 ocdecio 给出了答案"，尽管这里有很多很好的答案，正确"答案的选择纯粹是主观的.在这种情况下，鉴于当前的技术状态，他的回答与我认为真正的最佳实践相吻合.然而，这是一个我完全期望发展的领域，所以事情很可能会发生变化.我要感谢所有做出贡献的人，我已经为所有我认为给出深思熟虑的答案的人投了票.
Update 2: I've given the "answer" to ocdecio although there are many great answers here and the choice of the "right" answer is purely subjective. In this case, his answer squared with what I think is truly the best practice given the current state of technology. This is an area that I fully expect to evolve, however, so things may well change. I'd like to thank everyone who contributed, I've upvoted everyone who I think gave a thoughtful answer.
推荐答案
至少 6 年来，我一直在使用我自己的 ORM，它基于一个非常简单的概念:投影.每个表都投影到一个类中，并根据类定义动态生成 SQL.它仍然需要我了解 SQL，但它处理了 90% 的简单 CRUD，而且我从不需要管理连接等——它适用于主要的数据库供应商.
For at least 6 years I have been using my own ORM that is based on a very simple concept: projection. Each table is projected into a class, and SQL is generated on the fly based on the class definition. It still requires me to know SQL but it takes care of the 90% simple CRUD, and I never had to manage connections, etc - and it works for the major DB vendors.
我对我所拥有的感到满意，没有发现任何值得放弃的东西.
I'm happy with what I have and didn't find anything worth dropping it for.
这篇关于Linq to SQL 是不是没有抓住重点?ORM 映射器(SubSonic 等)不是次优解决方案吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
