Wrap the ISession

[Matteo Migliore]

Hi!

I wrapped the ISession interface to an IRepository<T> (in a little more complex way), now I've the problem to expose the eager loading feature
so I want to have this:
IRepository<T> : IEagerLoading<T>
...

IEagerLoading<T> : IQueryable<T>
{
    IEagerLoading<T> Include<TRelated>(Expression<Func<T, TRelated>> path);
}

On the IRepository<T> I want to write customerRepository.Include(x => x.Addresses).Include(x => x.MainAddress);

Do you know a simple way to do that?

Thanks,
Matteo.

[Ramon Smits]

I think that you are on the wrong path here. I would not at all wrap the ISession as I don't see what kind of issue you are trying to resolve.

IMHO it is better to wrap your query strategy in a seperate class in a seperation of concern kind of way. Then you can easily put optimizations in this class if needed and you can easily test this as well.

--
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/-/030pE7I4fScJ.
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.

--

Ramon

[Matteo Migliore]

I'm working on a package that is used in production http://nuget.org/packages/EyeSoft.Data.Nhibernate.

The source is here http://hyperionsdk.codeplex.com.

The package that uses all this things is http://nuget.org/packages/EyeSoft.Domain.

Here you can find an example of a domain and why I want to wrap all the ISession  http://hyperionsdk.codeplex.com/SourceControl/changeset/view/78296#1759677.

Thanks if you can :),
Matteo.

[Ramon Smits]

ORM switching is a bad idea. Either invest in a technology to get the best performance or don't. You want to some how mix to the and that is the reason why I mention to use seperation of concern. This way you can put your query logic in an ORM independant technology with linq expressions and when performance is problematic you can add other implementations with technology specific optimizations without worrying about IRepository/NHibernate/ORM stuff at all in the class dependent on that implementations.

Most optimizations are fetching all data at once by having efficient queries and minimizing roundtrips so I don't understand how abstracting your ORM helps with that.

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

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.

--

Ramon

[Matteo Migliore]

I've production code now, I can't change the way I'm following, I've to solve the problem.

If it was EF the method is only the Include(Expression<Func<T, TProperty>>), easier to wrap :).

[Ramon Smits]

Can't you put the query in a method and then inherit from the uow handler which overrides this query method with a NHibernate specific optimization?

On Mon, Aug 13, 2012 at 9:52 PM, Matteo Migliore <matteo....@gmail.com> wrote:

--

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/-/030pE7I4fScJ.
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.

--

Ramon

[Matteo Migliore]

I would avoid that, because my UnitOfWork(s) and Repository are ORM agnostic.

I'm thinking to use AutoMapper to materialize the objects before to output them outside
the Data Layer, so I can map an aggregate to itself using a custom AutoMapper profile
to don't load the properties I don't want, probably the best way is to send out the domain
a DTO, also to the service (in DDD is made so), so don't have an IRepository<Customer>
but have an IRepository<CustomerDto> (I don't expose IRepository, only custom Repository).

What do you think?

The problem is that my customer now is using my package but it has a lot of legacy code that
uses directly the ISession, but now it has migrated to my IRepository so I commented
all the Fetch/FetchMany/ThenFetch/ThenFetchMany to be compilable but now obviously
there's a big issue with performance.

[Matteo Migliore]

Hi.

I just saw the post on StackOverflow, but it is incomplete, there isn't a full example of the concept.

Can you try my "Domain package" on Nuget and see how to write the missing FetchXxx methods?

I would also have a unique method called Include like Entity Framework, to simplify the client code.

Thanks,
Matteo.

On Wednesday, August 15, 2012 8:50:41 PM UTC+2, Randy Burden wrote:

Hi. Take a look at the following StackOverflow post below. At my job, we are currently using a slightly modified version of the referenced post to wrap NHibernate's .Fetch() methods. Our organization has moved away from direct ISession usage to an IRepository<T> with great success.

StackOverflow post: http://stackoverflow.com/a/5742158/670028

As a side note, I really don't get the people bashing the concept of abstracting away the ISession. Who cares about the switching ORMs argument. I like the benefit that developers can simply have an IRepository<T> injected into the constructor of their classes and just use standard LINQ to do what they need to do to get the job done. Behind the IRepository<T>, you can implement whatever you want such as your own custom Unit of Work that makes sense for what your organization and application consider a unit of work. I'm not advocating that there is no need for direct access to the ISession at certain times but making it standard practice to use an IRepository<T> dramatically normalizes how queries look across the organization.

When people are allowed to use the ISession freely, you end up with all of NHibernate's various query APIs spread all over your code base with HQL, Critieria API, and QueryOver all jumbled up. Show a newcomer to the organization all of that craziness and they can feel overwhelmed. Or show them a standard IRepository<T> query where they are just using standard LINQ to query over an IQueryable<T> and it makes much more sense with almost no learning curve and the best part is that they can just get done quicker without all the ramp up of learning a new API ( or 3 APIs ) for data access.

All I'm saying is that there are legit reasons to wrap up the ISession and abstract away NHibernate internals. I can attest that it can be done and is being done successfully in an enterprise environment.