Extending Linq To Nhibernate provider, in combination with Dynamic Linq problem

[murki]

Hey guys, I'm trying to extend the Linq provider and use Microsoft's
dynamic linq library, and having some problems in the middle. I have
posted a stackoverflow question here:
http://stackoverflow.com/questions/6267912/extending-linq-to-nhibernate-provider-in-combination-with-dynamic-linq-problem

Anyone has any idea what my problem might be about?

Regards,
-Miguel

[Fabio Maulo]

I can't see the sense of the usage of Dynamic-LINQ with NHibernate.

[murki]

Well maybe I'm missing something, the idea is that we have IRepository
interfaces that provide IQueryables of the entities, and then each
consumer can attach the predicates they need. The implementation of
IRepostiory could be Linq-to-sql, Entity Framework or NHibernate. For
the first two the dynamic queries work, for Nhibernate they don't.

I know Nhibernate already provides dynamic mechanisms like the
Criteria API, and HQL, but my consumers know nothing about that.

I don't know if that make much sense. Thanks!
-Miguel

[Fabio Maulo]

"IRepostiory could be Linq-to-sql, Entity Framework or NHibernate."

In your imagination perhaps, in the real world no.

Just put an enum in your domain and then try to use it with Linq2SQL or EF4.

[Gunnar Liljas]

Or more humbly put, the power of IQueryable and Linq is that it gives the developers a productive and strongly typed query syntax, where skills, not code, can be brought over to different data scenarios. 

It is already a well known fact that in-memory Linq behaves quite differently from "Linq to SomeDataBase", and L2S, EF and NH should be treated as "equally different" from each other. 

There may be perfectly valid reasons to put NHibernate behind a wrapper, such as limiting the range queryable types, but I can tell you from real experience in two concurrent projects (one with NH, the other with L2S) that a generic IRepository<T> is a really crippling concept.

If you want a data source agnostic data layer (extremely rare), you're better served by a much more explicit abstraction, e.g with methods like "GetNewsForHomePage".

That said, your need for string based Dynamic LINQ must have other reasons. What is the scenario?

/G

2011/6/9 Fabio Maulo <fabio...@gmail.com>

"IRepostiory could be Linq-to-sql, Entity Framework or NHibernate."

In your imagination perhaps, in the real world no.

Just put an enum in your domain and then try to use it with Linq2SQL or EF4.

--
You received this message because you are subscribed to the Google Groups "nhusers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/gVTGfwC8XtoJ.

To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[murki]

Thanks everybody for your responses.

Cheers,
-Miguel

On Jun 9, 3:25 pm, Gunnar Liljas <gunnar.lil...@gmail.com> wrote:
> Or more humbly put, the power of IQueryable and Linq is that it gives the
> developers a productive and strongly typed query syntax, where skills, not
> code, can be brought over to different data scenarios.
>
> It is already a well known fact that in-memory Linq behaves quite
> differently from "Linq to SomeDataBase", and L2S, EF and NH should be
> treated as "equally different" from each other.
>
> There may be perfectly valid reasons to put NHibernate behind a wrapper,
> such as limiting the range queryable types, but I can tell you from real
> experience in two concurrent projects (one with NH, the other with L2S) that
> a generic IRepository<T> is a really crippling concept.
>
> If you want a data source agnostic data layer (extremely rare), you're
> better served by a much more explicit abstraction, e.g with methods like
> "GetNewsForHomePage".
>
> That said, your need for string based Dynamic LINQ must have other reasons.
> What is the scenario?
>
> /G
>

> 2011/6/9 Fabio Maulo <fabioma...@gmail.com>

[Harald M.]

On 8 Jun., 13:10, Fabio Maulo <fabioma...@gmail.com> wrote:
> I can't see the sense of the usage of Dynamic-LINQ with NHibernate.

We do this. Why?

We write a new part of our software where we want to use Linq('s
programming model; we create functions that create query snippets
etc.etc.).
NHIb's Linq is not yet production-ready (yes, I know, I should work on
those || and Any bugs ... please give me a little time).
So we actually use Linq2Sql AND NHib3 optionally/in parallel for a few
more months; then we'll decide (I favor NHib3 with fixed bugs; but I
have to remain open to Linq2Sql, with which we do have more
experience).
Moreover, as we are (willingly) bound to Linq, we need
the .Select(...) part to create dynamic results from a GUI (this is
not totally true .. a much smaller .Select generator would suffice;
but right now, we take with DynamicLinq for simplicity).
And hence, we end up with - for the moment - NHib+DynamicLinq (as well
as Linq2Sql+DynamicLinq).

Yes, we know that NHib3 and Linq2Sql behave differently at well-known
places (null constant in ==, association definitions, inheritance
modes come to mind); we know that we can bypass these differences.
What we do not know are the bugs (e.g., we seem to have found one in
Linq2Sql with sorting when the sort expression is of type
Func<T,object> - this works most of the time, but apparently not in
one case; and there might be more bugs than the Any and Join problems
in NHib3).

So that's the reason for this - in our case pure project risk
minimization - strategy.

Regards
Harald

[Dan B]

Isn't ICriteria better suited to building up dynamic queries?

[Gunnar Liljas]

You're welcome, but I'd really like to help you with your current scenario. Can you explain in more detail?

/G

2011/6/10 murki <mur...@gmail.com>