> Or take LINQ to SQL. LINQ to SQL is great. Usually. If
> you're using it exactly as they intended. When we wanted to
> make some of our models automatically supply some query
> parameters, though...well, let's just say there was a lot
> of T4 templating involved to get around sealed classes, and
> leave it there.
I solved what sounds to be a similar problem using reflection and the Linq ExpressionBuilder class(and related classes). It actually turned out really clean and powerful.
That's roughly what we did: the T4 template work in combination with a cache that a) takes LINQ expression trees with invalid, though ITable-compliant, classes; b) swaps out the ITable-compliant classes for LINQ to SQL's Table classes; c) compiles the expression tree into SQL; d) caches it, so we only have to pull this stunt once.
The power of Microsoft's tools is that this is possible. The bane of them is that it was necessary in the first place.
I solved what sounds to be a similar problem using reflection and the Linq ExpressionBuilder class(and related classes). It actually turned out really clean and powerful.