you’re resolving your dependencies manually instead of having them injected… looking back on this post, i did the same thing in the example which i would no longer recommend

i’ll write a new post with an example that hopefully makes this clear… it’ll be based on the NhRequestHandler that you’ve already seen in another post though

public IResponse Execute()
{
var sessionProvider = IoC.Container.Resolve();
var junkRepository = IoC.Container.Resolve();
sessionProvider.StartSession();
junkRepository.Save(junk);
sessionProvider.EndSession();
return new EmptyResponse();
}

In the repositories I’m hoping that i can do something similar.

public IEnumerable GetJunk()
{
var sessionProvider = IoC.Container.Resolve();
var queryString = “select j from Junk j”;
var query = sessionProvider.GetCurrentSession().CreateQuery(queryString);
query.SetResultTransformer(new DistinctRootEntityResultTransformer());
return query.List();
}

The obvious problem i’m having when i do this is the session not being handled correctly. Am I off base by using this at all in the repository and should just stick with command objects?
I’m guessing this is where the UnitofWork could come in, but i’m a little fuzzy on how to do this.

I’m up for an example because i have a lot of questions like this and others.

what kind of example do you want?

Agatha resolves the request handler for the current request, and that request handler simply declares all the dependencies that it needs to handle the request. Agatha automatically releases the resolved request handler, and the request handler disposes of its dependencies

public void InsertCategory(ProductCategoryDTO dto)
{
using(var uow = Container.Resolve())
{
using (ITransaction transaction = uow.CreateTransaction())
{
try
{
var pc = CreateProductCategoryFromDto(dto);
var repository = Container.Resolve();
repository.SaveOrUpdate(pc);
transaction.Commit();
}
catch(SomeException e)
{
transaction.Rollback();
}
}
}
}

Or do you have a better/more elegant way?

Thanks in advance,
Morten Jacobsen

I have found this article extremely useful. I just thought I’d share one minor change I made. When injecting the IUnitOfWork from my controller, the session was being started even if my action was not using the database (because the constructor was being fired). It was then throwing an error on the next action to use the UoW because the previous session hadn’t been disposed. I added an extra method to the IUnitOfWork:

public interface IUnitOfWork : IDisposable
{
..
///
/// Starts the Unit of Work
///
/// Itself
IUnitOfWork Start();
}

And moved the setActiveSession logic out of the constructor and into this method. Because it returns itself it can still be used in the using block.

using (unitOfWork.Start())(

Again, many thanks for the article. Keep up the good work.

that service layer implementation is just some example code… in my real service layer, the IUnitOfWork instance is indeed injected instead of resolved manually

A quick question regarding your implementation of the service layer. Doesn’t the explicit call to IoC container, Container.Resolve()
limit your testability. It would seem to make sense to pass in the UoW on the constructor.

How do you test this?

I like the use of the using statement however the only disadvantage I could see is if you wanted to chain service method calls. With each method call the UoW would dispose of the Session.

Thanks,

I would love to see one simple example… how does one persuade you?

You don’t have a full example of this ? Thanks

Thanks! I think that is steering me in the right direction. I am trying to learn how to apply several patterns (IOC, DI, etc) all at once while learning a new ORM AND trying to do it all in the web. This learning seems steep.

C

every class that needs request-scoped state would talk to something that implements IRequestState, but they would never know the specific type of the actual implementation. So, if you have another assembly which contains only your businesslayer (and no reference to System.Web), then you should have classes which need request-state depend on an IRequestState instance.

At runtime, the container will inject AspNetRequestState into each class which has a dependency on IRequestState, but none of those classes will even know that they are talking with AspNetRequestState. Since the business assembly is running within the ASP.NET context, your AspNetRequestState can do anything it wants with the current HttpContext. Or, if the business assembly is running in a different context (in a WCF service for instance) then the container would be configured to inject WcfRequestState. None of the classes that need request-state would know anything about either AspNetRequestState or WcfRequestState though… they just know IRequestState

Hope that answers your question

I was trying to write a small Web App to try and put all of these pieces together. I have also implemented the ActiveSessionManager to use the IRequestState which I would pass in AspNetRequestState in the Constructor.

So here is where I am getting lost.

I am assuming that the “GetAllProductCategories” method (last bit of code in the post) would be in a seperate assembly from the web application.

If the IOC Container is Resolving the UnitOfWork, but, it is not in the web application, how will the AspNetRequestState be able to pull the Nhibernate Session out of HTTPContext?

Thanks

Chuck

I was just coming on to post that I had found your source code on the site. Again, between you and Steve B. I have learned sooo much about NHibernate.

Cheers.

C

http://davybrion.com/blog/2008/06/disposing-of-the-idisposable-implementation/

The ClearReferences method as used in this post has been replaced by the DisposeUnmanagedResources method, though they don’t have the same purpose. The ClearReferences method was basically a mistake

Umm, but to make a long answer short: it was also called in Dispose

Thanks! This is really putting together some pieces that I was missing while working with NHibernate. Just a quick question, I could not find on your site the implementation of Disposable that calls the ClearReferences() method. At what point in Disposable does that get called?

Chuck