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映射器有一些想法.
我喜欢Linq和Sql，并喜欢用本机开发语言表达数据访问逻辑(或一般说来CRUD操作)，而不必处理C#和SQL之间的阻抗不匹配".例如，要为业务层返回与ObjectDataSource兼容的Event实例列表，请使用:
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类(yuck)的新创建实例的成员. /p>
所以那是为什么喜欢Linq/SubSonic/etc的人的原因.我同意.
但是，从更大的角度看，我看到了许多错误的地方.我的感觉是，Microsoft也看到了错误，这就是为什么它们架构宇航员，尤其是在微软， Linq to Sql意识到这不是一个真正的数据管理工具:在C#中，您仍然无法轻松完成许多事情，并且它们的目标是对其进行修复.您会看到这体现在背后的野心中Linq to Entities，有关革命性质的博客文章Linq甚至是 LinqPad挑战.
的问题在于它假定SQL是问题所在.也就是说，为了减轻轻微的不适感(SQL和C#之间的阻抗不匹配)，Microsoft建议在创可贴(Linq to SQL或类似的东西)就可以的情况下，等效于太空服(完全隔离).
据我所知，开发人员足够聪明，可以掌握关系模型，然后将其聪明地应用于开发工作中.实际上，我再说一遍，Linq to SQL，SubSonic等已经太复杂了:学习曲线与掌握SQL本身并没有太大不同.由于在可预见的将来，开发人员必须掌握SQL和关系模型，所以我们现在面临着学习两种查询/CRUD语言的问题.更糟糕的是，Linq通常很难测试(您没有查询窗口)，将我们从正在执行的实际工作中删除了一层(生成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指出了一篇标题为越南.虽然花了一些时间才能上手，但是读起来却很有趣.其次，AnSGri指出了Joel Spolsky最著名的作品之一:泄漏抽象定律.它不完全是话题，但它很接近，很值得一读.
更新2:尽管这里有很多很棒的答案，但我给奥克迪西奥提供了答案"，而正确"答案的选择纯粹是主观的.在这种情况下，鉴于当前的技术水平，他的回答与我认为的确是最佳实践相吻合.我完全希望这是一个可以发展的领域，因此情况可能会发生变化.我要感谢所有做出贡献的人，对我认为给出了深思熟虑的每个人都表示赞赏.
至少六年来，我一直在使用自己的ORM，它基于一个非常简单的概念:投影.将每个表投影到一个类中，并根据该类定义即时生成SQL.它仍然需要我了解SQL，但是它可以处理90％的简单CRUD，而且我也不必管理连接等-并且它适用于主要的数据库供应商.
我对自己拥有的东西感到满意，没有发现值得抛弃的东西.
I'd like the community's take on some thoughts I've had about Linq to Sql and other ORM mappers.
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 })
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).
So, that is why people like Linq/SubSonic/etc. and I agree.
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.
So, what is wrong?
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.
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.
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".
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
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.
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?
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.
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.
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屋！
