views:

83

answers:

1

The rationale:

HQL and NH criteria are NHibernate specific constructs and as such they are server side DAL implementation details. I do not want them to "leak" to the client side. So, our client side provides LINQ expressions for the server to process.

Seems legitimate to me, some, however, think otherwise and so I would like to know why.

Thanks.

+3  A: 

The argument against accepting expressions from (or exposing IQueryable<> to) the client side is that it allows non-client logic like filtering and joining to happen in the "wrong" place. If the client is exposing the wrong data, you now have two places the check: the client-side logic and the logic behind the DAL. Essentially, it makes it too easy to not separate your concerns.

That said, there are certainly times that deliberate and careful use of those techniques can improve your application. For example, using an IQueryable<> is a great way to support client-side sorting and partitioning (skip/take) that are executed efficiently by the server rather than on the result set. The counter-argument is that you should just provide sort and partition parameters in the DAL.

Ultimately use what make sense for your application. If you give yourself too much rope and find yourself hanging, you can always refactor later.

dahlbyk