<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Playing Nice With Service Locators</title>
	<atom:link href="http://kohari.org/2008/06/18/playing-nice-with-service-locators/feed/" rel="self" type="application/rss+xml" />
	<link>http://kohari.org/2008/06/18/playing-nice-with-service-locators/</link>
	<description>Rambling and occasional wisdom from Nate Kohari</description>
	<lastBuildDate>Wed, 01 Sep 2010 18:45:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: NHibernate, MVC and Ninject &#171; Damian test blog</title>
		<link>http://kohari.org/2008/06/18/playing-nice-with-service-locators/comment-page-1/#comment-2803</link>
		<dc:creator>NHibernate, MVC and Ninject &#171; Damian test blog</dc:creator>
		<pubDate>Thu, 29 Jul 2010 13:44:55 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=89#comment-2803</guid>
		<description>[...] In the sample I&#8217;ve also added a ServiceLocator. When using StructureMap if you don&#8217;t mind&#160;coupling your code to StructureMap (probably not the best idea) you can can configure your container in one place, then make calls to ObjectFactory anywhere you need to. The Ninject kernel doesn&#8217;t work this way, so we need to keep a reference to a configured kernel in a place that can be accessed by the code. Nate Kohari, the author on Ninject provides a good example of the&#160;Service Locator&#160;pattern with Ninject&#160;on his blog. [...]</description>
		<content:encoded><![CDATA[<p>[...] In the sample I&rsquo;ve also added a ServiceLocator. When using StructureMap if you don&rsquo;t mind&nbsp;coupling your code to StructureMap (probably not the best idea) you can can configure your container in one place, then make calls to ObjectFactory anywhere you need to. The Ninject kernel doesn&rsquo;t work this way, so we need to keep a reference to a configured kernel in a place that can be accessed by the code. Nate Kohari, the author on Ninject provides a good example of the&nbsp;Service Locator&nbsp;pattern with Ninject&nbsp;on his blog. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Singleton Pattern &#171; Richards blog</title>
		<link>http://kohari.org/2008/06/18/playing-nice-with-service-locators/comment-page-1/#comment-168</link>
		<dc:creator>The Singleton Pattern &#171; Richards blog</dc:creator>
		<pubDate>Sat, 06 Dec 2008 21:24:36 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=89#comment-168</guid>
		<description>[...] The singleton is still a great concept and a great tool to have in a developers arsenal but now I take a different approach by using an IoC (Inversion of Control/Dependency Injection) container called ninject which provides a Singleton attribute which provides uses the IoC facilities to maintain a reference to a single instance of an object. I feel that this approach will play well with WPF databinding because I believe the attribute will allow calls to be directed at the class without having knowledge of the factory maintaining the instance (Note: yet to confirm this in practice). I believe that other developers have opted for adopting service locators instead of singleton patterns. A blog post about the argument of IoC vs Service Locators is provided here: http://kohari.org/2008/06/18/playing-nice-with-service-locators/. [...]</description>
		<content:encoded><![CDATA[<p>[...] The singleton is still a great concept and a great tool to have in a developers arsenal but now I take a different approach by using an IoC (Inversion of Control/Dependency Injection) container called ninject which provides a Singleton attribute which provides uses the IoC facilities to maintain a reference to a single instance of an object. I feel that this approach will play well with WPF databinding because I believe the attribute will allow calls to be directed at the class without having knowledge of the factory maintaining the instance (Note: yet to confirm this in practice). I believe that other developers have opted for adopting service locators instead of singleton patterns. A blog post about the argument of IoC vs Service Locators is provided here: <a href="http://kohari.org/2008/06/18/playing-nice-with-service-locators/" rel="nofollow">http://kohari.org/2008/06/18/playing-nice-with-service-locators/</a>. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate Kohari</title>
		<link>http://kohari.org/2008/06/18/playing-nice-with-service-locators/comment-page-1/#comment-167</link>
		<dc:creator>Nate Kohari</dc:creator>
		<pubDate>Sat, 21 Jun 2008 12:36:57 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=89#comment-167</guid>
		<description>Yeah, Autofac is a very cool framework, and Nicholas has a lot of good ideas. I would imagine that Ninject could support something similar, but I haven&#039;t looked into it much at this point.</description>
		<content:encoded><![CDATA[<p>Yeah, Autofac is a very cool framework, and Nicholas has a lot of good ideas. I would imagine that Ninject could support something similar, but I haven&#8217;t looked into it much at this point.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fredrik Kalseth</title>
		<link>http://kohari.org/2008/06/18/playing-nice-with-service-locators/comment-page-1/#comment-166</link>
		<dc:creator>Fredrik Kalseth</dc:creator>
		<pubDate>Sat, 21 Jun 2008 08:53:22 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=89#comment-166</guid>
		<description>Hmm, your blog stripped the angle brackets from my comment above; the RegisterGeneratedFactory method should take a generic parameter of type EventWatcherFactory for the code I posted to make any sense :)</description>
		<content:encoded><![CDATA[<p>Hmm, your blog stripped the angle brackets from my comment above; the RegisterGeneratedFactory method should take a generic parameter of type EventWatcherFactory for the code I posted to make any sense :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fredrik Kalseth</title>
		<link>http://kohari.org/2008/06/18/playing-nice-with-service-locators/comment-page-1/#comment-165</link>
		<dc:creator>Fredrik Kalseth</dc:creator>
		<pubDate>Sat, 21 Jun 2008 08:49:48 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=89#comment-165</guid>
		<description>Have you looked at Autofac? It has a pretty neat feature called &#039;delegate factories&#039; (http://code.google.com/p/autofac/wiki/DelegateFactories) which can be used to solve this problem. Using your example, you could create a delegate like

public delegate EventWatcher EventWatcherFactory(string eventName, Action callback)

and register that with the Autofac container

containerBuilder.RegisterGeneratedFactory(new TypedService(typeof(EventWatcher)));

This would then allow anyone who needs to create EventWatchers to request the injection of the EventWatcherFactory, and use it to create event watchers. This has the added bonus of being typesafe and refactor friendly.

I would love to see Ninject offer something similar :)</description>
		<content:encoded><![CDATA[<p>Have you looked at Autofac? It has a pretty neat feature called &#8216;delegate factories&#8217; (<a href="http://code.google.com/p/autofac/wiki/DelegateFactories" rel="nofollow">http://code.google.com/p/autofac/wiki/DelegateFactories</a>) which can be used to solve this problem. Using your example, you could create a delegate like</p>
<p>public delegate EventWatcher EventWatcherFactory(string eventName, Action callback)</p>
<p>and register that with the Autofac container</p>
<p>containerBuilder.RegisterGeneratedFactory(new TypedService(typeof(EventWatcher)));</p>
<p>This would then allow anyone who needs to create EventWatchers to request the injection of the EventWatcherFactory, and use it to create event watchers. This has the added bonus of being typesafe and refactor friendly.</p>
<p>I would love to see Ninject offer something similar :)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
