<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: dashCommerce V.Next &#8211; Dependency Injection / IoC</title>
	<atom:link href="http://chriscyvas.com/2008/08/04/dashcommerce-vnext-dependency-injection-ioc/feed/" rel="self" type="application/rss+xml" />
	<link>http://chriscyvas.com/2008/08/04/dashcommerce-vnext-dependency-injection-ioc/</link>
	<description></description>
	<lastBuildDate>Sun, 29 Nov 2009 16:44:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Paul Knopf</title>
		<link>http://chriscyvas.com/2008/08/04/dashcommerce-vnext-dependency-injection-ioc/#comment-48</link>
		<dc:creator>Paul Knopf</dc:creator>
		<pubDate>Wed, 01 Oct 2008 07:07:24 +0000</pubDate>
		<guid isPermaLink="false">http://chriscyvas.wordpress.com/?p=33#comment-48</guid>
		<description>lblRetailPriceAmount.Text = ServiceRegistry.CurrencyService.GetConvertedAmount(_product.RetailPrice, convertCode);

Lets encapsulate this logic in a composite label control. What do you think?

We can use this method for other things like localized resources.</description>
		<content:encoded><![CDATA[<p>lblRetailPriceAmount.Text = ServiceRegistry.CurrencyService.GetConvertedAmount(_product.RetailPrice, convertCode);</p>
<p>Lets encapsulate this logic in a composite label control. What do you think?</p>
<p>We can use this method for other things like localized resources.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chriscyvas</title>
		<link>http://chriscyvas.com/2008/08/04/dashcommerce-vnext-dependency-injection-ioc/#comment-47</link>
		<dc:creator>chriscyvas</dc:creator>
		<pubDate>Thu, 07 Aug 2008 05:05:33 +0000</pubDate>
		<guid isPermaLink="false">http://chriscyvas.wordpress.com/?p=33#comment-47</guid>
		<description>Ok, so this isn&#039;t really a ServiceLocator - it just plays one on TV. :) I was trying to avoid having ICatalogService catalogService = resolver.Resove() all over the place. Good idea? Bad? Why? Why not?</description>
		<content:encoded><![CDATA[<p>Ok, so this isn&#8217;t really a ServiceLocator &#8211; it just plays one on TV. <img src='http://s.wordpress.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  I was trying to avoid having ICatalogService catalogService = resolver.Resove() all over the place. Good idea? Bad? Why? Why not?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chriscyvas</title>
		<link>http://chriscyvas.com/2008/08/04/dashcommerce-vnext-dependency-injection-ioc/#comment-46</link>
		<dc:creator>chriscyvas</dc:creator>
		<pubDate>Tue, 05 Aug 2008 21:40:03 +0000</pubDate>
		<guid isPermaLink="false">http://chriscyvas.wordpress.com/?p=33#comment-46</guid>
		<description>Yes, I understand - and it probably is a ServiceLocator in actuality - kind of - as the code looks like this:

&lt;code&gt;
  public static class ServiceRegistry {

    #region Member Variables

    private static IDependencyResolver dependencyResolver = new UnityDependencyResolver(&quot;Store&quot;);

    #endregion



    public static ICatalogService CatalogService {
      get {
        return dependencyResolver.Resolve(&quot;catalogService&quot;);
      }
    }

    public static ICurrencyService CurrencyService {
      get {
        return dependencyResolver.Resolve(&quot;currencyService&quot;);
      }
    }
}
&lt;/code&gt;


We definitely want to be able to swap out at the service layers and they don&#039;t have too many dependencies outside of themselves - what they do have is built up via the providers. Maybe this is a poor example or am I missing something?</description>
		<content:encoded><![CDATA[<p>Yes, I understand &#8211; and it probably is a ServiceLocator in actuality &#8211; kind of &#8211; as the code looks like this:</p>
<p><code><br />
  public static class ServiceRegistry {</p>
<p>    #region Member Variables</p>
<p>    private static IDependencyResolver dependencyResolver = new UnityDependencyResolver("Store");</p>
<p>    #endregion</p>
<p>    public static ICatalogService CatalogService {<br />
      get {<br />
        return dependencyResolver.Resolve("catalogService");<br />
      }<br />
    }</p>
<p>    public static ICurrencyService CurrencyService {<br />
      get {<br />
        return dependencyResolver.Resolve("currencyService");<br />
      }<br />
    }<br />
}<br />
</code></p>
<p>We definitely want to be able to swap out at the service layers and they don&#8217;t have too many dependencies outside of themselves &#8211; what they do have is built up via the providers. Maybe this is a poor example or am I missing something?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jbland</title>
		<link>http://chriscyvas.com/2008/08/04/dashcommerce-vnext-dependency-injection-ioc/#comment-45</link>
		<dc:creator>jbland</dc:creator>
		<pubDate>Mon, 04 Aug 2008 21:56:16 +0000</pubDate>
		<guid isPermaLink="false">http://chriscyvas.wordpress.com/?p=33#comment-45</guid>
		<description>Looks more like a service locator than &quot;pure&quot; DI. It works, but i prefer constructor injection (never got around to setter injection). It makes coupling a bit looser and dependencies more explicit (i simply have to look at the constructor to know whats required). It also permits for optional dependencies (simply have ctor signatures without the optional dependencies). Much better is that the DI framework takes care of all the wiring, and upfront we know we have a usable object, dependencies satsfied, or we get fat nasty exceptions.</description>
		<content:encoded><![CDATA[<p>Looks more like a service locator than &#8220;pure&#8221; DI. It works, but i prefer constructor injection (never got around to setter injection). It makes coupling a bit looser and dependencies more explicit (i simply have to look at the constructor to know whats required). It also permits for optional dependencies (simply have ctor signatures without the optional dependencies). Much better is that the DI framework takes care of all the wiring, and upfront we know we have a usable object, dependencies satsfied, or we get fat nasty exceptions.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
