Hi Fabio,
what that means is that we are using a very generic Repository pattern
like this for all data access in our system(simplified)
public interface IRepository<T>
{
T Get(int id);
void Save(T);
IQueryable<T> Query;
}
This maps to not only databases but also to flat files, xml files, a
few webservices and so forth and allows the developers to use a common
way of querying data in the system. Also the users build dynamic
queries in the system, we then build some expression trees based on
these dynamic queries and use them in the IQueryable part directly.
We are looking into replacing two existing ORMs(one of them is EF v1
which has pretty good linq support but absolutely horrible mapping
support and even worse query building performance in special cases)
with nhibernate because of some advanced mapping scenarios to a legacy
database that have recently appeared where only Nhibernate can do the
job as far as we can see.
And this is why we would hope to use the Linq part and IQueryable<> of
Nhibernate, so we could just plug it in without modifying anything
else in the system.
On Apr 14, 2:21 pm, Fabio Maulo <[email protected]> wrote:
> "we are using a repository pattern that relies heavily on IQueryable<> so
> switching from to Criteria or QueryOver is pretty much not an option."
>
> What that mean ?
>
> For me:
> You have an ORM with at least 4 options to write OO queries. Instead write
> an architecture that allow you the usage of all options you are following
> guide lines of an ORM which have just one option.
>
> Question:
> I would know the reason of such decision.
>
> Thanks.
>
>
>
>
>
>
>
>
>
> On Thu, Apr 14, 2011 at 9:12 AM, rotgut <[email protected]> wrote:
> > The interesting thing is that if i use QueryOver<> it also does an
> > inner join.
>
> > It should always be inner join when i have mapped references as not
> > nullable, as it is right now it is returning some Properties without a
> > Broker, that wont happen when it is using inner joins.
>
> > I would also hate to expand all my linq queries with Broker.Name !=
> > null or something like that to get the same output as the criteria/
> > queryover version and the linq provider still uses a left outer join
> > if i do this "hack".
>
> > Inner joins in my current database is much much faster than left outer
> > joins and also we are using a repository pattern that relies heavily
> > on IQueryable<> so switching from to Criteria or QueryOver is pretty
> > much not an option.
>
> > Is there any way to force the linq provider to use inner joins?
>
> > On Apr 13, 8:50 pm, "Harald M." <[email protected]> wrote:
> > > Oops!!! - I overlooked your addition "Not.Nullable()". It might force
> > > Criteria to optimize the join to an inner, whereas Linq (at this time)
> > > definitely does not do this.
> > > But if the pointer is not nullable anyway, there should not be any
> > > difference between an inner and an outer join - would you agree? So
> > > then there is no bug.
> > > Or is your database highly performance sensitive to outer joins?
> > > Or do you use "dangling pointers" - i.e., the column itself is not-
> > > null, but the target values in the Broker table need not exist? ...
> > > then, I fear, you are at a boundary case of the Linq provider - and
> > > adding that p.Broker != null still might not help (but
> > > p.Broker.BrokerId != null should).
>
> > > Regards
> > > Harald
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> >http://groups.google.com/group/nhusers?hl=en.
>
> --
> Fabio Maulo
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
