tags:

views:

202

answers:

1

I am currently using a CMS which uses an ORM with its own bespoke query language (i.e. with select/where/orderby like statements). I refer to this mini-language as a DSL, but I might have the terminology wrong.

We are writing controls for this CMS, but I would prefer not to couple the controls to the CMS, because we have some doubts about whether we want to continue with this CMS in the longer term.

We can decouple our controls from the CMS fairly easily, by using our own DAL/abstraction layer or what not.

Then I remembered that on most of the CMS controls, they provide a property (which is design-time editable) where users can type in a query to control what gets populated in the data source. Nice feature - the question is how can I abstract this feature?

It then occurred to me that maybe a DSL framework existed out there that could provide me with a simple query language that could be turned into a LINQ expression at runtime. Thus decoupling me from the CMS' query DSL.

Does such a thing exist? Am I wasting my time? (probably the latter)

Thanks

+1  A: 

Hi, this isn't going to answer your question fully, but there is an extension for LINQ that allows you to specify predicates for LINQ queries as strings called Dynamic LINQ, so if you want to store the conditions in some string-based format, you could probably build your language on top of this. You'd still need to find a way to represent different clauses (where/orderby/etc.) but for the predicates passed as arguments to these, you could use Dynamic LINQ.

Note that Dynamic LINQ allows you to parse the string, but AFAIK doesn't have any way to turn existing Expression tree into that string... so there would be some work needed to do that.

(but I'm not sure if I fully understand the question, so maybe I'm totally of :-))

Tomas Petricek
I think you understood the gist of my question - thanks. As for expressions, I really only wanted to go from a string to LINQ, not the other way, so that's no problem.
Schneider
Dynamic LINQ looks useful, but you are right. I would have to provide seperate fields for my where and orderby clauses. No big problem I guess. P.S. I'm still looking for more answers if anyone has ideas.
Schneider