-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 
Author Message
 Post subject: Best use of Sessions and Session Factories?
PostPosted: Mon Jul 04, 2005 5:17 pm 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Hi guys,

I'm developing an assembly to be provided as an API which will contain a collection of classes to encapsulate a set of required business data and logic. This API will then, in a specific instance, be wrapped by an ASP.NET web service.

My question is, what would the best way to manage the sessions and session factories throughout the classes?

I was thinking that the assembly could have an object with a static method that could create and expose a singleton session factory which is configured to load the hbm files for it's own assembly. A reference to that session factory could then be placed in an ASP.NET static Application variable to allow the ASP.NET application to instantiate the session factory once and then a session-per-request could be created to manage the rest of the process.

Doe this sound reasonable?

Where I'm really concerned though, is that the methods containing business logic for some of the classes need to be aware of and create other NHibernate aware objects internally.

This somehow doesn't seem like great OO practice, but I'm pretty new to this and I'm not sure where I'm supposed to go next.

If I did follow this approach then how would I manage the sessions inside each method call? Do I have to pass a session into each and every method so that they can share? Or am I on completely the wrong track?

When using the API in a non-ASP.NET application how would I manage sessions - exactly the same way? Create a singleton session factory and then use it throughout the application to manage the objects (including passing the session to the methods so that they can manage their internal NHibernate objects)?

I think I might be chasing my tail here - can anyone give me a couple of tips?

Cheers,

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jul 12, 2005 2:48 pm 
Regular
Regular

Joined: Mon May 16, 2005 2:15 pm
Posts: 59
Good points all.

I really think that Sessions should not be handled in the Presentation layer. And also, for good ortaganal design I also don't thing the Domain objects should know anything about NHibernate either.

I think the DAO layer should do this. Or, it should use helper classes. This seperates concern as much as possible.

But, I know alot of people are doing sessions in the ASP.Net page. Perhaps rather than this you might want to have Business Objects Layer or Service Layer that does all the communication with the UI Layer and NHibernate. This keeps the Domain objects agnostic to the persistence framework. It also keeps the UI agnostic. If you want to chage persistence mechanisms you just have to swap our your Server layer. If it has the same API then the UI won't notice a difference.

As you can see, I have been mulling over these issues too.

BOb


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 15, 2005 8:42 am 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Thanks Pilotbob,

After much reading, pondering and cranial depilation (hair pulling) I think I'm going to use the following approach:

I'll create an assembly that will operate as my API. This will contain all the domain classes and the persistence implementation. The domain objects will be 'rich' objects (avoiding Fowler's 'anaemic' tag) which will contain the vast majority of their own business logic.

The persistence layer will be bound to private or internal fields (rather than properties) so that I can use the internal fields to set properties when the business logic in the method of one class needs to create and modify instances of other domain object without being hindered by the restrictions placed on publicly available properties (which the consumers will).

To start using the API the consumer will call a static method of a 'configurator' class which will generate and hold a hidden Session Factory instance in either a singleton of that class, or, if the context != null it will store it in an ASP.NET Application variable - this will allow for an application wide usage in a web environment as well as in a standalone app.

If I provide a property to get access to the factory then the consumer could request a session object if they want to create their own transaction (if, for example, they wanted to call mutiple methods as an atomic unit). If the Session Factory and Session/Transaction objects have wrappers (a la Cuyahoga) that are provided to the consumer of the API I can further insulate them from the persistence implementation.

Any methods implementing business logic can create their own internal session to access the persistence layer from this central Session Factory or can alternately use one that is passed in by the consumer.

Using this model the consumer could still have long running transactions (stored in an ASP.NET session) if they wanted to.

Admittedly this approach means that my API layer is pretty irrevocalby tied to NHibernate going forward, but unless I use an 'anaemic' object model then I don't think I've got much option...and the 'anaemic' model just doesn't appeal.

And hey, the whole idea of NHibernate is that I can change my RDBMS when I want to without changing the actual persistence mechanism, and since NHibernate is all done with interfaces I really still could change it out if I had to! Not that I see that as being likely...

Does all of this make sense? I may well be raving...not much sleep lately... ;)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 15, 2005 12:04 pm 
Newbie

Joined: Sat Jul 02, 2005 12:42 pm
Posts: 11
Location: Manchester, UK
Here is a 'helper' class that I use when using NHibernate with ASP.NET.

It handles the work of creating the config and session factory objects and loading the config as well as creating individual session objects for each request (and then closing them).

http://blogs.intesoft.net/simon/articles/16.aspx

I either include static methods in the domain objects as shown at the beginning or else leave them as POCO's and use a set of data access classes for them all.

I like the way it reads though with them in the classes themselves, eg:

IList customers = Customer.GetListByRegion( "North" );

_________________
- Simon

http://www.intesoft.net/


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 16, 2005 7:06 am 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Hey Simon,

Thanks for the link - good article and clear code!

Looks like you're taking a similar approach to the one I'm considering - I have a preference for the way code reads when the process of obtaining objects is through static members too.

The idea of data access classes seems, in some way, to be better design because it allows for looser coupling of the domain objects though. For instance, in the environment I'm working in there's a strong interdependence between domain objects in our business logic. Is that a bad thing? The only thing I don't like about data access classes is that it seems to make more sense to have the methods in the classes themselves from a readability and simplicity perspective. *sigh* Which way to go?

I like the way you're checking the HttpContext to see whether it's a web environment as well - it's the road I was looking down. I think I might do something very similar to your helper - the only thing I want to do differently is reduce the consumer's exposure to the Session and SessionFactory objects themselves - there's a lot of functionality there that I don't want consumers to see and I don't want them directly coupled with NHibernate in case a choice is made in the future to change it out.

Cheers,

Symon.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 16, 2005 3:03 pm 
Newbie

Joined: Sat Jul 02, 2005 12:42 pm
Posts: 11
Location: Manchester, UK
Thanks :o

I agree that having separate data classes is probably better design on paper but in reality I am not going to change the data layer and I suspect that in practice most systems don't. If I wanted to switch from NHibernate to some other OR/M then I could just as easily change the static methods in the POCOs as the methods in the data layer. I guess it keeps everything in one place though.

The check for the HttpContext is to help when unit testing. Originally I created a fake context in the unit tests but I find this way is easier. The reason the config and factory are exposed was originally so I could call other bits of NHIbernate (like the DDL export) although I added a method just for this.

The whole thing could probably be made internal to a data access layer so that the use of NHibernate would be totally hidden from the app. However, I think this separation is overdone sometimes - you have to design and code your app to the best features of the data provider very often unless you only use the basic features of them that are all common.

_________________
- Simon

http://www.intesoft.net/


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 17, 2005 9:40 am 
Senior
Senior

Joined: Thu Jun 02, 2005 5:03 pm
Posts: 135
Location: Paris
Quote:
The check for the HttpContext is to help when unit testing


Interesting. In my case the framework I'm developing will be used in both ASP.NET and in other non-web based environments, so doing the check allows me to make a descision about where I store the factory and session with easy access from the domain objects based on the environment I'm running under.

You may not be using it that way, but it certainly helps for me, so thanks for helping consolidate the idea! :)

The main reason that I want to hide the NHibernate functionality from the consumer of my framework is that the users of the framework should know nothing at all about the persistence of the objects. If they had access to the session then they could start breaking functionality while using it, which could leave behind nasty little surprises in the DB.

Cheers,

Symon.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.