You're welcome, glad it makes sense to someone else!
In general there's a one-to-one correlation between UoW and session - very
occasionally I break that, but only if there's a strong reason.
Session factory is built in Global.asax Application_Start, and then registered
as a Castle Windsor 'facility' (along with UoW as a standard service) - by
doing that, all we need to do is expose UoW as a parameter for the BL class
constructors and everything is injected automagically.
Completely agree that domain entity shouldn't know anything about NHibernate -
that's a smell IMO.
public class PersistenceFacility : AbstractFacility
{
private static ILog s_log =
LogManager.GetLogger(typeof(PersistenceFacility));
/// <summary>
/// Initialise the facility by building the NHibernate
configuration and then registering the session factory
/// </summary>
protected override void Init()
{
s_log.Debug("Initialising persistence facility");
var cfg = BuildDatabaseConfiguration();
s_log.Debug("Registering persistence facility components");
Kernel.Register(
Component.For<ISessionFactory>()
.UsingFactoryMethod(_ =>
cfg.BuildSessionFactory())
.LifestyleSingleton(),
Component.For<ISession>()
.UsingFactoryMethod(k =>
k.Resolve<ISessionFactory>().OpenSession(k.Resolve<IInterceptor>()))
.LifestylePerWebRequest(),
Component.For<IStatelessSession>()
.UsingFactoryMethod(k =>
k.Resolve<ISessionFactory>().OpenStatelessSession())
.LifestylePerWebRequest()
);
}
From: [email protected] [mailto:[email protected]] On Behalf Of
Sean Farrow
Sent: 26 April 2013 10:30
To: [email protected]
Subject: RE: [nhusers] NHibernate architecture in a clas library
Hi Pete,
Thank for this-it makes sense.
Two follow-up questions, I'm assuming you don't use a shared session across
unit of work instances?
Secondly where do you build your session factory?
I'm trying not to make the parent class aware of NHibernate.
Cheers
Sean.
From: [email protected] [mailto:[email protected]] On Behalf Of
Pete Appleton
Sent: 26 April 2013 09:48
To: [email protected]
Subject: RE: [nhusers] NHibernate architecture in a clas library
Currently, my preference is to inject a 'unit of work' class into my BL classes
- the UoW contains an injected ISession with trivial transaction handling code
as below. So basically, I treat ISession as the boundary for the DAL with the
BLL consuming it directly. Previously, I tried using repositories & facades
but (for me) it just introduced a lot of complexity & maintenance burden
without bringing any benefits - we found were fighting the façade &
'repository' design instead of working with it
Simplified example:
class UnitOfWork {
ISession NhSession { get; set; } // Injected via IoC,
Castle Windsor in my case
T DoWork<T>(Func<ISession, T> work) {
T retVal;
using(var tran = this.NhSession.BeginTransaction()) {
retVal = work(this.NhSession);
tran.Commit();
}
}
}
class MyBusinessLogic {
UnitOfWork UoW { get; set; } // Injected via IoC
SomeDTO DoSomething(SomeDTO request) {
try {
return UoW.DoWork(session -> {
});
catch { .... }
}
}
I emphasise that this is just something I've come up with and am happy with,
I'm sure that there are many other approaches with equal or better merit!
/Pete
From: [email protected] [mailto:[email protected]] On Behalf Of
Sean Farrow
Sent: 25 April 2013 23:37
To: [email protected]
Subject: [nhusers] NHibernate architecture in a clas library
Hi Fokes:
I'm currently working on an application which is using NHibernate for some of
it's data access.
I have a bunch of clases that write to a database.
I've currently set up a façade class to hide all details of data
access-saving/loading etc.
Is this the best design for multiple classes, I don't really want to go down
the repository route, as only 3 database tables are being hit-the table being
hit depends on the entity passed in to the save method as this is saved as xml
and I'd ideally like to hold the session factory somewhere, the library is used
in both sharepoint webparts and a console application.
Any ideas greatfully accepted, as it seems my design is convoluted, I carn't
see where though
Cheers
Sean.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
