|
|
Rank: Administration
Groups: Administration
, Member
Joined: 10/7/2008
Posts: 505
Points: 1,515
|
I am continuing way through my journey to get 100% understanding of Cuyahoga. I do not mean using and developing modules for Cuyahoga, but Cuyahoga itself. How the nuts and bolts work from entering the site domain name through the ASP.NET HTTP pipeline, to the first page and then on from there. Is the following a (roughly) correct understanding of how Cuyahoga uses Castle.Windsor? Global.asax.cs > > Application_Start() > Bootstrapper.InitializeContainer(); > IWindsorContainer container = new CuyahogaContainer(); (Container created and components from web.config > services.config (and programatically) are registered). > IoC.Initialize(container); (Inititialize the static Windsor helper class so it can be accessed from 'IoC.Container'  > the Global.asax.cs implements the IContainerAccessor which: CuyahogaContainer GetContainer() returns the Container. Why this and IoC.cs also (not from context)? I understand IoC and why it is used. A question though: Since this is all running on 'Application_Start' I am assuming this is done once and is then available to all subsequent users of the site for the lifetime the application runs (not each visitor). If there are no visitors for 20mins or so  and the worker process 'Application Ends' then Container.Dispose(); Is this roughly correct or am I far off base? Thanks in advance for any clarification. Is there a similar breakdown for how NHibernate used? 
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
Constructor wrote:
Is the following a (roughly) correct understanding of how Cuyahoga uses Castle.Windsor?
Global.asax.cs >
> Application_Start()
> Bootstrapper.InitializeContainer();
In Cuyahoga 2.0 it is. Quote:> IWindsorContainer container = new CuyahogaContainer(); (Container created and components from web.config > services.config (and programatically) are registered). > IoC.Initialize(container); (Inititialize the static Windsor helper class so it can be accessed from 'IoC.Container' > the Global.asax.cs implements the IContainerAccessor which: CuyahogaContainer GetContainer() returns the Container. Why this and IoC.cs also (not from context)? We could do without IContainerAccessor. The static IoC class replaces it. It's left from the initial Windsor integration. Quote:I understand IoC and why it is used. A question though: Since this is all running on 'Application_Start' I am assuming this is done once and is then available to all subsequent users of the site for the lifetime the application runs (not each visitor). If there are no visitors for 20mins or so and the worker process 'Application Ends' then Container.Dispose(); Is this roughly correct or am I far off base? Yes, this is correct, but I don't know for sure if the app still shuts down after 20 mins of no activity Quote:Is there a similar breakdown for how NHibernate used? We're using Castle's NHibernateIntegration Facility. During Windsor initialization, the NH config is read from facilities.config. This means setting up the Configuration and adding Cuyahoga.Core as assembly to load mappings from. After that, when a module is loaded for the first time that implements INHibernateModule, the module assembly is scanned for mappings which are added to the Configuration. Each time after adding a new module, the sessionfactory is rebuilt. When everything is in place, we use ISessionManager.OpenSession() to obtain the NH session and perform our queries, updates, etc.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 10/7/2008
Posts: 505
Points: 1,515
|
Quote:We're using Castle's NHibernateIntegration Facility. During Windsor initialization, the NH config is read from facilities.config. This means setting up the Configuration and adding Cuyahoga.Core as assembly to load mappings from.
After that, when a module is loaded for the first time that implements INHibernateModule, the module assembly is scanned for mappings which are added to the Configuration. Each time after adding a new module, the sessionfactory is rebuilt.
When everything is in place, we use ISessionManager.OpenSession() to obtain the NH session and perform our queries, updates, etc. Excellent, thanks a lot! I pretty much understand IoC and NHibernate use, pages and modules. I still have a the feeling inside I am not satisfied with my level of understanding yet. Just a nagging feeling. I want to be able to run through the application in my head and visualise it. I still have yet to absorb 'where' the container IS. This may sound stupid but thinking that the container is available from inside the static IoC class (at a specific point in time) for example is different than it just being there at an application level. I know that: IContainerAccessor containerAccessor = HttpContext.Current.ApplicationInstance as IContainerAccessor; and IContainerAccessor is implemented in the Global.asax.cs and this returns IoC.Container. I still have that feeling I am missing something. How do I best visualise this and really absorb the concept? Do I have to just learn to trust and have faith that the container IS really just there during the lifetime of the application  I will continue. I still have other Castle libs to dig through. Transaction management and a few others to get an overview of.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
Constructor wrote:How do I best visualise this and really absorb the concept? Do I have to just learn to trust and have faith that the container IS really just there during the lifetime of the application Well, in a sense yes. Application_Start happens once and there the static IoC class is initialized when nothing bad happens.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 10/7/2008
Posts: 505
Points: 1,515
|
Thanks. I can pretty much navigate the whole source and follow what is happening. I have spent a couple of days really looking deep and trying to get an understanding of exactly what is going on. When I went back to my modules it felt really good to understand 'the outside' and not just the module projects (and immediate surroundings). As time goes on hopefully it will all become more fluent and maybe intuition/insight will come into play when working. I still have some Castle stuff to really absorb (validators/transaction).
|
|
Rank: Newbie
Groups: Member
Joined: 4/8/2010
Posts: 7
Points: 21
|
Sorry to dig up such an old post, but I thought my query would follow on from what was asked before.
I am also trying to disect how this beauty works, I think i have my head round the IoC et al, but im trying to understand what
superseeds what in the core. I can see that the individual decoupled services that are injected from the services.config, effectivly
replacing the CoreRepository. However I can only find examples of the lagacy data access (where the CoreRepository is pulled back from
the HttpContext in the GeneralPage, and the GetObjectByID etc are used) as in ViewProfile.ascx.cs. Obviously you are keeping the legacy
stuff in there so you dont break older modules and existing functionality, but is this the intended way for data access at this level in the controls themselves?
Can the decoupled services be called directly?
Also my client requires very high level of nUnit tests, from Data Access of a test database, testing in a IMDB etc. I notice that the test project is quite light,
i dont suppose you could point me in the direction of how I could implement our own Dao Tests to flesh them out (i did have a look at other modules, but they seem very module specific)?
Thanks guys
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 10/7/2008
Posts: 505
Points: 1,515
|
Take a look at the V2.0 Trunk modules: Code:public ArticleModule(IContentItemService< Article> contentItemService, ICategoryService categoryService, ICommentService commentService)
{
this._contentItemService = contentItemService;
this._categoryService = categoryService;
this._commentService = commentService;
} This also may be of help: http://ayende.com/Blog/archive/2009/04/28/nhibernate-unit-testing.aspx
|
|
Rank: Newbie
Groups: Member
Joined: 4/8/2010
Posts: 7
Points: 21
|
Beautiful! exactly what I needed!!
presumably if one was to rewrite the GeneralPage class in the web project to utilise the individual decoupled services, instead of:
this._coreRepository = HttpContext.Current.Items["CoreRepository"] as CoreRepository;
we could write something like:
IUserService userService = (IUserService)BS.Core.Util.IoC.Container["core.userservice"];
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
kmoo01 wrote:
presumably if one was to rewrite the GeneralPage class in the web project to utilise the individual decoupled services, instead of:
this._coreRepository = HttpContext.Current.Items["CoreRepository"] as CoreRepository;
we could write something like:
IUserService userService = (IUserService)BS.Core.Util.IoC.Container["core.userservice"];
It's even simpler: IUserService userService = Cuyahoga.Core.Util.IoC.Resolve< IUserService >();
|
|
|
Guest |