<?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: Attributes? We Don&#8217;t Need No Stinkin&#8217; Attributes</title>
	<atom:link href="http://kohari.org/2008/06/08/attributes-we-dont-need-no-stinkin-attributes/feed/" rel="self" type="application/rss+xml" />
	<link>http://kohari.org/2008/06/08/attributes-we-dont-need-no-stinkin-attributes/</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: Imran</title>
		<link>http://kohari.org/2008/06/08/attributes-we-dont-need-no-stinkin-attributes/comment-page-1/#comment-146</link>
		<dc:creator>Imran</dc:creator>
		<pubDate>Tue, 21 Jul 2009 20:47:37 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=98#comment-146</guid>
		<description>?! Just realised how old this post was! Just started using Ninject for silverlight since castle windsor is not available.</description>
		<content:encoded><![CDATA[<p>?! Just realised how old this post was! Just started using Ninject for silverlight since castle windsor is not available.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Imran</title>
		<link>http://kohari.org/2008/06/08/attributes-we-dont-need-no-stinkin-attributes/comment-page-1/#comment-147</link>
		<dc:creator>Imran</dc:creator>
		<pubDate>Tue, 21 Jul 2009 20:46:16 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=98#comment-147</guid>
		<description>Nate: Looks good I’ll definitely be using the auto wiring feature in future. I think attributes tend to bother people as they want to keep classes as clean as possible as the type system grows. In a large system with lots of dependencies I wouldn&#039;t want to have to decorate constructors or properties with attributes but in a smaller system it probably wouldn&#039;t matter. Anyhow, It’s nice to have the option.</description>
		<content:encoded><![CDATA[<p>Nate: Looks good I’ll definitely be using the auto wiring feature in future. I think attributes tend to bother people as they want to keep classes as clean as possible as the type system grows. In a large system with lots of dependencies I wouldn&#8217;t want to have to decorate constructors or properties with attributes but in a smaller system it probably wouldn&#8217;t matter. Anyhow, It’s nice to have the option.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate Kohari</title>
		<link>http://kohari.org/2008/06/08/attributes-we-dont-need-no-stinkin-attributes/comment-page-1/#comment-145</link>
		<dc:creator>Nate Kohari</dc:creator>
		<pubDate>Thu, 12 Jun 2008 12:59:47 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=98#comment-145</guid>
		<description>@Chris: Yeah, I think that most .NET dependency injection frameworks use XML for type bindings because they are patterned on Java, which didn&#039;t get annotations until recently. In contrast, the CLR was born with attributes, so it makes sense (at least to me!) to use them. Ninject was largely inspired by Guice&#039;s alternative take on bindings.

However, I completely understand the concern some people have with intermingling their infrastructure with higher layers of their application. I think this largely stems from frameworks requiring the use of ugly attributes, which need to carry all sorts of information beyond simple tagging. I&#039;ve tried very hard to avoid that sort of thing in Ninject. :)

Thanks for the comment!</description>
		<content:encoded><![CDATA[<p>@Chris: Yeah, I think that most .NET dependency injection frameworks use XML for type bindings because they are patterned on Java, which didn&#8217;t get annotations until recently. In contrast, the CLR was born with attributes, so it makes sense (at least to me!) to use them. Ninject was largely inspired by Guice&#8217;s alternative take on bindings.</p>
<p>However, I completely understand the concern some people have with intermingling their infrastructure with higher layers of their application. I think this largely stems from frameworks requiring the use of ugly attributes, which need to carry all sorts of information beyond simple tagging. I&#8217;ve tried very hard to avoid that sort of thing in Ninject. :)</p>
<p>Thanks for the comment!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Wash</title>
		<link>http://kohari.org/2008/06/08/attributes-we-dont-need-no-stinkin-attributes/comment-page-1/#comment-144</link>
		<dc:creator>Chris Wash</dc:creator>
		<pubDate>Thu, 12 Jun 2008 03:46:00 +0000</pubDate>
		<guid isPermaLink="false">http://kohari.org/?p=98#comment-144</guid>
		<description>Hey Nate,

Saw this on DZone and found it interesting.

Attributes for injection are a good thing IMO.  Coming from a Java-side, they haven&#039;t always been around.  Pre-&quot;annotations&quot;, most Java DI frameworks relied on wiring of dependencies in XML, which was tedious, but ultimately pulled all of the wiring out into configuration.  That meant it could live outside the code, keeping the code cleaner and more abstract, and also allowing you to switch things out without having to recompile anything.

Once annotations and Guice hit the scene, this really took a backseat because you could introduce typesafety into the mix.

You may be interested to check out this blog entry for the skinny on what&#039;s &quot;bleeding edge&quot; in this arena ATM:

http://solutionsfit.com/blog/2007/11/09/thoughts-on-webbeans-and-stereotypes/</description>
		<content:encoded><![CDATA[<p>Hey Nate,</p>
<p>Saw this on DZone and found it interesting.</p>
<p>Attributes for injection are a good thing IMO.  Coming from a Java-side, they haven&#8217;t always been around.  Pre-&#8221;annotations&#8221;, most Java DI frameworks relied on wiring of dependencies in XML, which was tedious, but ultimately pulled all of the wiring out into configuration.  That meant it could live outside the code, keeping the code cleaner and more abstract, and also allowing you to switch things out without having to recompile anything.</p>
<p>Once annotations and Guice hit the scene, this really took a backseat because you could introduce typesafety into the mix.</p>
<p>You may be interested to check out this blog entry for the skinny on what&#8217;s &#8220;bleeding edge&#8221; in this arena ATM:</p>
<p><a href="http://solutionsfit.com/blog/2007/11/09/thoughts-on-webbeans-and-stereotypes/" rel="nofollow">http://solutionsfit.com/blog/2007/11/09/thoughts-on-webbeans-and-stereotypes/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
