Appropriate lifecycle for repository classes using Castle Windsor

微笑、不失礼 提交于 2019-11-29 16:01:16

Rule of thumb is - component should not depend on other components that will outlive it.

In other words, it's ok for transient to depend on singleton, or per-web-request component, but not the other way around.

The way I approach Repository - UoW scenario is my UoW is per web request, but repositories are stateless and transient.

When you say repository, I assume you mean a repository which abstracts an Nhibernate session. If so, then it should never ever be singleton. If it is a singleton, then multiple request threads will trample over one another's session. I personally have seen a few defects around this. Since Castle's default life cycle is singleton, if a developer forgets to explicitly mark a component's life cycle, bad things start happening.

It should ideally be per-request (following the unit of work concept). The only rider to this approach is that you have enable Asp.net compatibility mode in your application (if it's not Asp.net that is). The other way is to mark a repository transient. But the downside to this approach is that Castle will instantiate a new repository object every time a component needs it.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!