我可以扩展LINQ-to-SQL支持的运算符吗? [英] Can I extend the operators that LINQ-to-SQL supports?

问题描述

如果我想做的足够糟糕，是否可以在LINQ-to-SQL中添加其他LINQ构造(如创建自己的LINQ提供程序那样)?例如，许多内置的LINQ运算符(XYZ.Any())直接转换为SQL(例如IF EXISTS(XYZ)).

If I wanted to badly enough, could I add additional LINQ constructs to LINQ-to-SQL (as I would be able to if creating my own LINQ provider)? For instance, many of the built-in LINQ operators (XYZ.Any()) get directly translated to SQL (e.g. IF EXISTS(XYZ)).

如果我需要专门的构造，我是否甚至可以扩充集合，还是必须将其放入实际的LINQ-to-SQL提供程序中?

If I needed a specialized construct, would I even be able to augment the set, or does this have to be baked into the actual LINQ-to-SQL provider?

我将如何添加新的操作员实现? C#扩展方法是否足以胜任工作?

How would I go about adding a new operator implementation? Are C# extension methods enough of a hook to do the job?

如果答案是肯定的，那么有人愿意通过LINQ-to-SQL生成的动态SQL替换很多(全部)存储过程功能吗?

If the answer is yes, would someone so inclined be able to replace much (all?) of sproc capability via the dynamic SQL generated by LINQ-to-SQL?

推荐答案

理论上，您可以向LINQ提供程序添加对任意表达式的支持，但Pavel认为LINQ to SQL不能作为起点是正确的.我将研究SubSonic或NHibernate，它们也正在开发LINQ提供程序.提供程序支持表达式后，您只需要在IQueryable<T>上构建等效的扩展方法-反映System.Linq.Queryable即可了解详细信息.

In theory you could add support for arbitrary expressions to a LINQ provider, but Pavel is correct that LINQ to SQL would not work as a starting point. I would look into SubSonic or NHibernate, which also have LINQ providers under development. Once the provider supports an expression, you would just need to build an equivalent extension method on IQueryable<T> - reflect System.Linq.Queryable for details.

也就是说，解析表达式树绝对不适合胆小的人.除非您真的对AST理论感兴趣，否则以常规"方式扩展OSS ORM可能会更容易.

That said, parsing expression trees is definitely not for the faint of heart. Unless you're really interested in AST theory, it would probably be easier to just extend an OSS ORM in a "normal" way.

这篇关于我可以扩展LINQ-to-SQL支持的运算符吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！