what to do with rhino commons?

[Tyler Burd]

Hi all,

I have a host of projects that make extensive use of Rhino Commons (UnitOfWork, IRepository, etc.).  I know Rhino Commons is going to be obsolete with the move to Git, but I'm curious to know how people are handling this.  Are you removing Rhino Commons from your active projects?  Are you keeping a private version of RC to apply changes/fixes to?  I ask because I am in the middle of a very large project that uses RC, and I wonder if I should ditch it before it's too late.  Do people not use RC anymore?

Thanks!

-tyler burd

[Craig Neuwirt]

I use it pretty heavily too, so I am not sure whats gonna happen either

[Ayende Rahien]

The idea right now is to just leave it on SVN.

A LOT of people are using it, and I am not going to take it away.

I am probably going to let someone else take the lead role there, though.

[Tyler Burd]

That makes sense.  Out of curiosity, Ayende, are you no longer using anything from RC in your projects?

[Ayende Rahien]

No, I am not.

The last time I did was over a year ago. I am doing a lot more surgical things now, not a big bang framework approach

[Craig Neuwirt]

Ayende,

  I really like the UoW abstractions in rhino.commons.  What is your preferred way to deal with NHibernate Sessions nowadays?  Without scopes or UoW, how do your components get access to a session?

thanks,
 craig

[Ayende Rahien]

Ambient session from the container, most often

[rg]

Please save the Binsor!
R

[Ayende Rahien]

To be absolutely honest, with the Windsor FI, I am not sure there is a lot of place for Binsor.

On Thu, Sep 10, 2009 at 8:59 PM, rg <rafal.g...@gmail.com> wrote:

Please save the Binsor!

R

[Craig Neuwirt]

I use Binsor for all my configurations.  I never put anything in app.config/web.config
I agree FI reduced its dependency a little, but it is still a great choice when you really need configurations.

[Nathan Stott]

I disagree.  Binsor, on several occasions, has saved me a lot of headache by allowing me to reconfigure my apps in production without having to recompile them.  Windsor Fl does not allow for this.

[Ayende Rahien]

Yes, that is a good scenario for Binsor.

But it is actually not something that I tend to do

[rg]

I'd miss Binsor very much, this is the best config mechanism I have
ever used. Sometimes compilation is not an option, especially when you
are modifying something in production system, that is why I have moved
some frequently modified application parts to Boo scripts or Boo-based
DSLs.
R

[Tyler Burd]

When you say "ambient session from the container", do you mean actually injecting the ISession?  Do you accomplish this via child containers when needing a session-per-web-request or something similar?  Or do you use a per-web-request life-cycle when you register ISession with the container?

[Ayende Rahien]

Guy!!!!!!!!

Binsor isn't going away, and this isn't a wake!

It is going to be there, it is still going to be useful!

[Ayende Rahien]

I am talking about something like:

kernel.Register(

  Component.For<ISession>()

     .FactoryMethod( () => HttpContext.Items["current-session"]) )

);

[Craig Neuwirt]

ROFL

I think we are all just a little unclear of the final shape of the rhino set of tools so we are just trying to protect our investments ;-)

[Tyler Burd]

Just when you think you know the ins and outs of Castle.  I have lots of changes to make to my current codebase now.  FactoryMethod FTW!

[Craig Neuwirt]

This would need to be transient. right?

[Ayende Rahien]

Yes, forgot that

[Mike Nichols]

I've been doing something similar but using NHibernate's builtin ThreadStaticSessionContext.Bind(session); or WebSessionContext.Bind(session); depending on environment.

[Ayende Rahien]

Exactly, the actual session management is outside the container.

It is only an accessor for this.

[rg]

Guy, I'm just making sure.


On Sep 10, 8:34 pm, Ayende Rahien <aye...@ayende.com> wrote:
> Guy!!!!!!!!Binsor isn't going away, and this isn't a wake!

[Bart Reyserhove]

Interesting stuff. I would love to see a blog post on this topic.

btw, would it not be interesting to move rhino commons to git anyway. Just to keep everything on one location. Afterwards someone in this group could take the lead in maintaining it. It does not need much maintenance anyway. Maybe just sometimes review an occasional patch.

[Ayende Rahien]

You are right, thank you for volunteering to do this.

[Bart Reyserhove]

Damn for what did I volunteer exactly ;-)

[Bart Reyserhove]

Don't mind at all reviewing patches but I'm totally lost in git for the moment, so if somebody could move it, that would be great. I can then get up to speed on git to be able to maintain rhino commons.

[Tim Barcz]

Speaking of RhinoCommons...I just updated from SourceForge trunk and can't build...

Can someone please shoot me a zip of the binaries?

--
Tim Barcz
Microsoft ASPInsider
http://timbarcz.devlicio.us
http://www.twitter.com/timbarcz

[Martin Nilsson]

How does your repositories looks like? Because you can't take the dependency to ISession as a ctor? I'm replacing Rhino Commons with plain session management but I'm not sure how to interact between my services and repositories. Can you give a brief example. Something like this

ProductService:
public void Save(Product product) {
  using(var session = ?.GetSession)
  using(var tx = session.BeginTransaction())
  {
    repository.Add(product);
    tx.Commit();
  }
}

ProductRepository:
public void Add(Product product) {
   session.SaveOrUpdate(product);   
}

Does your repository have a dependency to IKernel maybe?

[Jason Meckley]

I inject a session as a ctor dependency like this

class Service
{
private readonly ISession session;
public Service(ISession session)
{
this.session = session;
}

public void DoWork(int id)
{
var entity = session.Load<Entity>(id);
session.Delete(entity)
}
}

class SessionResolver : ISubDependencyResolver
{
private readonly ISessionFactory factory;
public SessionResolver(ISessionFactory factory)
{
this.factory = factory;
}

public object Resolve(...)
{
return new SessionAdapter(factory);
}

public bool CanResolve(...)
{
return typeof(ISession).IsAssignableFrom
(dependency.TargetType);
}
}

class SessionAdapter : ISession
{
private readonly ISessionFactory factory;
public SessionAdapter(ISessionFactory factory)
{
this.factory = factory;
}

private ISession session { get { return factory.GetCurrentSession
(); } }

private T Load<T>(object id)
{
return session.Load<T>(id);
}

private Delete(object entity)
{
return session.Delete(entity);
}

//the rest of the ISession members...

}

On Sep 18, 9:25 am, Martin Nilsson <mffmar...@gmail.com> wrote:
> How does your repositories looks like? Because you can't take the dependency
> to ISession as a ctor? I'm replacing Rhino Commons with plain session
> management but I'm not sure how to interact between my services and
> repositories. Can you give a brief example. Something like this
>
> ProductService:
> public void Save(Product product) {
>   using(var session = ?.GetSession)
>   using(var tx = session.BeginTransaction())
>   {
>     repository.Add(product);
>     tx.Commit();
>   }
>
> }
>
> ProductRepository:
> public void Add(Product product) {
>    session.SaveOrUpdate(product);
>
> }
>
> Does your repository have a dependency to IKernel maybe?
>
> On Thu, Sep 10, 2009 at 8:35 PM, Ayende Rahien <aye...@ayende.com> wrote:
> > I am talking about something like:
>
> > kernel.Register(  Component.For<ISession>()
> >      .FactoryMethod( () => HttpContext.Items["current-session"]) )
> > );
>

> > On Thu, Sep 10, 2009 at 9:33 PM, Tyler Burd <tylerb...@gmail.com> wrote:
>
> >> When you say "ambient session from the container", do you mean actually
> >> injecting the ISession?  Do you accomplish this via child containers when
> >> needing a session-per-web-request or something similar?  Or do you use a
> >> per-web-request life-cycle when you register ISession with the container?
>
> >> On Thu, Sep 10, 2009 at 12:20 PM, Ayende Rahien <aye...@ayende.com>wrote:
>

> >>> Yes, that is a good scenario for Binsor.But it is actually not something

> >>> that I tend to do
>

> >>> On Thu, Sep 10, 2009 at 9:06 PM, Nathan Stott <nrst...@gmail.com> wrote:
>
> >>>> I disagree.  Binsor, on several occasions, has saved me a lot of
> >>>> headache by allowing me to reconfigure my apps in production without having
> >>>> to recompile them.  Windsor Fl does not allow for this.
>
> >>>> On Thu, Sep 10, 2009 at 2:02 PM, Ayende Rahien <aye...@ayende.com>wrote:
>
> >>>>> To be absolutely honest, with the Windsor FI, I am not sure there is a
> >>>>> lot of place for Binsor.
>

[Valeriu Caraulean]

Shorter version to register an ISession in container and provide it using ISessionFactory:

container.Register(

Component
   .For<ISession>()
   .LifeStyle.Transient
   .UsingFactoryMethod(() => container.Resolve<ISessionFactory>().GetCurrentSession());

Cheers :)

[Jason Meckley]

I like that too :)

On Sep 18, 11:46 am, Valeriu Caraulean <caraul...@gmail.com> wrote:
> Shorter version to register an ISession in container and provide it using
> ISessionFactory:
>
> container.Register(
> Component
>    .For<ISession>()
>    .LifeStyle.Transient
>    .UsingFactoryMethod(() =>
> container.Resolve<ISessionFactory>().GetCurrentSession());
>
> Cheers :)
>

[Ayende Rahien]

This is HORRIBLE.
You micro manage the session and remove from NH things like UoW, auto change tracking, persistence by reachability, etc.
Sessions should be managed by request / context, not in methods.

[Martin Nilsson]

Ok ok :)

I changed to this instead:
Kernel.Register(Component.For<ISession>().LifeStyle.Transient.UsingFactoryMethod(() => Kernel.Resolve<ISessionFactory>().GetCurrentSession()));

but then I get error:
"Type NHibernate.ISession is abstract.
As such, it is not possible to instansiate it as implementation of NHibernate.ISession service"

My solution now is this (not causing the above error):

ServiceClass:
  ctor(IUnitOfWorkFactory unitOfWorkFactory)

  In ServiceMethod:
    var session = unitOfWorkFactory.CurrentSession;
   
Questions:
1. Anyone knows why I get the above error?
2. Is my other solution (using IUnitOfWorkFactory) better/ok then?
3. You say that it's possible (better?) to take the ISession as a ctor arg. Will that be a different one for each req if my service class is singleton, although my session registration is transient?

[Ayende Rahien]

You need to register the factory facility.

[Martin Nilsson]

Yes, that was the case. Thanks.
My other question regarding taking ISession as a ctor argument. Then all those classes (queryobject, service and repository) needs to be transient?

[Ayende Rahien]

yes

[Simone Busoli]

That's what I don't like much with this approach, it's easy to do
something wrong, because you need to be very careful about the
lifestyle of your components, or you'll get into weird situations.
Ideally, I wouldn't like my components to be sort of aware of the
lifestyle of something they depend on, or, put in other words, I'd
expect them to get the right UoW regardless of whether they are
transient or singleton.

2009/9/21, Ayende Rahien <aye...@ayende.com>:

--
Inviato dal mio dispositivo mobile

[Ayende Rahien]

Simone,
*shrug*, the provide an ISession implementation that will access the ambient session.

[Simone Busoli]

I'm not sure I follow you, if I have a component which takes an
ISession as a ctor argument, I need to be careful to configure its
lifestyle to be "more transient" than that of the session itself,
right? Or I'll get an instance of the component with an out of date
session.

2009/9/21, Ayende Rahien <aye...@ayende.com>:

[Jason Meckley]

this is what I like about the SessionAdapter object I posted above.
you can use the default lifestyle of singleton. the actual session is
not retrieved (from the current session context) until you call a
member of session.

On Sep 21, 3:20 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> I'm not sure I follow you, if I have a component which takes an
> ISession as a ctor argument, I need to be careful to configure its
> lifestyle to be "more transient" than that of the session itself,
> right? Or I'll get an instance of the component with an out of date
> session.
>
> 2009/9/21, Ayende Rahien <aye...@ayende.com>:
>
>
>
> > Simone,
> > *shrug*, the provide an ISession implementation that will access the ambient
> > session.
>
> > On Mon, Sep 21, 2009 at 9:49 PM, Simone Busoli

> > <simone.bus...@gmail.com>wrote:

>
> >> That's what I don't like much with this approach, it's easy to do
> >> something wrong, because you need to be very careful about the
> >> lifestyle of your components, or you'll get into weird situations.
> >> Ideally, I wouldn't like my components to be sort of aware of the
> >> lifestyle of something they depend on, or, put in other words, I'd
> >> expect them to get the right UoW regardless of whether they are
> >> transient or singleton.
>
> >> 2009/9/21, Ayende Rahien <aye...@ayende.com>:
> >> > yes
>

> >> > On Mon, Sep 21, 2009 at 7:20 PM, Martin Nilsson <mffmar...@gmail.com>

> >> wrote:
>
> >> >> Yes, that was the case. Thanks.
> >> >> My other question regarding taking ISession as a ctor argument. Then
> >> >> all
> >> >> those classes (queryobject, service and repository) needs to be
> >> transient?
>
> >> >> On Sun, Sep 20, 2009 at 12:45 PM, Ayende Rahien <aye...@ayende.com>
> >> wrote:
>
> >> >>> You need to register the factory facility.
>
> >> >>> On Sun, Sep 20, 2009 at 10:15 AM, Martin Nilsson

> >> >>> <mffmar...@gmail.com>wrote:

> >> >>>>> <mffmar...@gmail.com>wrote:

[Simone Busoli]

Thanks Jason, I see it now, and it's an interesting approach, I never used it though. At the moment I am just doing UoW.Current when I need access to the UoW, but having a decorator which gives me the current one and still have it in the constructor is a nice way to accomplish that.

[Ayende Rahien]

There is a reason that I like to depend directly on ISession, and make my services transient.
It allows me to make assumptions with things like the session cache, uniqueness, etc.
With UoW.Current or interceptor approach, that is not the case.

[Jason Meckley]

Oren, could you share an example of how a transient service would
benefit, rather than a singleton? For example I don't see how managing
cache would be effected by the lifestyletype of the service.

On Sep 21, 6:50 pm, Ayende Rahien <aye...@ayende.com> wrote:
> There is a reason that I like to depend directly on ISession, and make my
> services transient.
> It allows me to make assumptions with things like the session cache,
> uniqueness, etc.
> With UoW.Current or interceptor approach, that is not the case.
>

> On Mon, Sep 21, 2009 at 11:47 PM, Simone Busoli <simone.bus...@gmail.com>wrote:
>
> > Thanks Jason, I see it now, and it's an interesting approach, I never used
> > it though. At the moment I am just doing UoW.Current when I need access to
> > the UoW, but having a decorator which gives me the current one and still
> > have it in the constructor is a nice way to accomplish that.
>

[Ayende Rahien]

The most important one, it could be stateful.
I like stateful components, they are much easier to work with

[Simone Busoli]

Do I read correctly or did you mean stateless?

2009/9/22, Ayende Rahien <aye...@ayende.com>:

[Jason Meckley]

pretty sure he meant stateful, as the services would be transient.

On Sep 22, 4:38 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> Do I read correctly or did you mean stateless?
>
> 2009/9/22, Ayende Rahien <aye...@ayende.com>:
>
>
>
> > The most important one, it could be stateful.
> > I like stateful components, they are much easier to work with
>
> > On Tue, Sep 22, 2009 at 3:53 PM, Jason Meckley

> > <jasonmeck...@gmail.com>wrote:

[Ayende Rahien]

State full

[Simone Busoli]

Fine, but then an example would be greatly appreciated :)

2009/9/22, Ayende Rahien <aye...@ayende.com>:

[petemounce]

I set up my WindsorContainer by sub-classing, and performing
registrations via FI-code within the constructor. The constructor
takes an XmlInterpreter as a parameter and passes this down to the
base-class, which means I can do the bulk of my registrations in code,
and override settings by using the config file (as long as I remember
to name all my components - which I do :-) ).

That said, I've never had to actually _use_ that in production - but
it's nice to have!

Regards
Pete

[Jason Meckley]

followup with my sessionadapter class (in case someone else tries to
use it). it appears that this is actually causing problems with my app
as a singleton. I didn't come across this until recently. the 2 "red
flags" where
1. objectdisposedexception which occurred when the container was
disposed. the session adapter was disposed and tried to dispose the
session, which wasn't there.
2. Future queries caused exceptions to throw about sqlstring
interceptors and List<> queries returned no results at all.

I did away with the adapter all together in favor of
container
.AddFacility<FactorySupportFacility>()
.Register(Component
.For<ISession>()
.Lifestyle.Is(LifestyleType.Transient)
.UsingFactoryMethod
(k=>k.Resolve<ISessionFactory>().GetCurrentSession()));

and transactions are managed with TransactionScope in web apps at the
beginning/ending of the request. this all feels much cleaner than
castle ATM and NH facility.

[Craig Neuwirt]

And you use the WebSessionContext from nhib for GetCurrentSession()?

[Jason Meckley]

@craig: correct. and my services are Transient as well.

On Sep 30, 1:38 pm, Craig Neuwirt <cneuw...@gmail.com> wrote:
> And you use the WebSessionContext from nhib for GetCurrentSession()?
>

[Craig Neuwirt]

cool, thanks