Showing posts with label CastleProject. Show all posts
Showing posts with label CastleProject. Show all posts

Friday, September 12, 2008

Still trying to figure out what DI/IoC but are afraid to speak up?

CodeProject - Design pattern – Inversion of control and Dependency injection

  • “Introduction
  • The problem – tight coupling
  • Solution
  • Principles of IOC
  • Ways of implementing IOC
  • Implementing the DI
  • What’s wrong with DI FACTORY?
  • The container way
  • Implementation using Windsor
  • References
  • Other Interview question PDF's

In this section we will discuss about how IOC and DI can help us build loosely coupled software architecture. I am not sure should we call this a design pattern or more of a approach. If you search around the web you will see lot of controversy on whether IOC is a design pattern or not. From my point of view it is a design pattern as it solves a problem context.
It would be great to see actual architectures implementing IOC using container oriented approaches. I am sure it will change the way we think about interaction between components.
So let’s understand in detail about IOC and DI.
…”
I’m not afraid to say it… I’m still trying to wrap my head around DI/IoC. There, I said it! I mean I get it but I am not sure I really "GET” it, know what I mean? (Note to Self: And I probably won't until I start coding with it, so start coding with it dummy!  ;)  (You can tell it's a Friday and I start talking to myself and calling myself a dummy... lol)

And I'd bet there's a silent developer majority our there who might be in the same boat as me. We've heard about it, seen few casts, read a few articles, but have yet to actually jump in...

The above Code Project has a few translation issues, but I liked it. I thought it presented one of the problems DI/IoC is trying to solve well and did a good job (with pictures! ;) explaining why DI/IoC is a good solution. The code samples, using Castle Windsor, are also easy to follow and understand.

This article will not be your only stop on the groking DI/IoC, but it's work a quick pitstop...
 

Friday, March 14, 2008

Another list from Scott Hanselman - Inversion of Control/Dependency Injection (IoC/DI) Frameworks for .Net

Scott Hanselman's ComputerZen.com - List of .NET Dependency Injection Containers (IOC)

"I'm trying to expand my mind around dependency injection in .NET (beyond the two frameworks I've personally used) and an starting to put together a list of .NET Dependency Injection Containers and IOC resources.

Here's what I've got so far. What am I missing?

..."

The major players are listed as are a few lessor known/mentioned ones. Make sure you also view the comments as there are a couple list there too. Also included are links for additional IoC/DI information.

Saturday, February 23, 2008

More IoC - A Castle Windsor and Unity Application Block Comparison

Matthew Podwysocki's Blog - IoC and the Unity Application Block - Going Deeper

"I thought after my recent F# post, I'd get back to the Unity post that was halfway done before the firestorm began...

In a previous post, I showed how easy it was to create a basic application using the Unity Application Block. I'm always finding new ways to solve my problems and new tools to do it.  Since Inversion of Control (IoC) containers are near and dear to my heart, I thought I'd investigate to see whether it meets my needs or not.  It's something you need to determine on your own, whether it works for you.  Some like Spring.NET, others StructureMap, Castle Windsor and so on.

...

Compare/Contrast with Windsor

Anyhow, today I will focus on a little compare/contrast with Castle Windsor just to show the different styles used.  I'm not going to say one is better than the other, because quite frankly, that's up to you to decide...  I want to thank Dustin Campbell for his help in getting a better code formatter via this post here.

..."

More IoC (Inversion of Control) reading material.

Also I believe this is my first reference to the very recently released Unity Application Block (a "lightweight extensible dependency injection container with support for constructor, property, and method call injection").

 

Related Past Post XRef:
Getting to know IoC (Inversion of Control) Container
Take a Lunch Break with Windsor IoC Container (part of the Castle Project)

Thursday, February 21, 2008

Getting to know IoC (Inversion of Control) Container

sfeldman.NET - Understanding IoC Container (Part 1)

"In a multi layered application architecture, loosely coupled code is more than a important. It's the basic which can either help the entire project progress, or drive it down the slope to the end (in the bad meaning of the word). One of the basics to keep coupling as low as possible is Inversion of Control (IoC) container.

I will try to show how to put in place a simple version of IoC container to allow loosely coupled design. The solution will contain several projects to emulate a layered application as much as possible. The choice of console application is only driven by intent to keep it as simple as possible.

..."

sfeldman.NET - Understanding IoC Container - Part 2

"I try to lower expectations in order not to be disappointed, but in this case I was asked by several individuals to address the fact that IoC container power is in the ability to "hook" implementer with the contract through an external file, leaving application code unaware of the actual implementer till the run-time, having no reference to implementers' assembly or whatsoever. I am going to expand the sample from the part 1 post to achieve that goal in a couple of days.

In the last post we left with the application with an ApplicationStartup() method that would register all implementers against the contracts they implement. That causes a serious coupling between the ConsoleApp assembly and the one that implements the XmlLogger, AssemblyTwo. This is not a good idea, especially when we want to be able to replace the implementer without touching/modifying the application itself (by recompiling it).

..."

I've been hearing and seeing discussions on IoC for a bit now and have been wanting to learn more about it (among the zillion other things I want to learn... Man I LOVE software development! :).

Based on my very limited understanding of IoC Container, it seems that it could help me solve a number of problems (some abstraction and coupling issues I want to address). I've reinvented the wheel a couple times implementing design and runtime abstraction/de-coupling, and I hate that... So I'm thinking/hoping that IoC Container can help me do it "right"...

(via Reflective Perspective - The Morning Brew #37)

Sunday, July 29, 2007

Take a Lunch Break with Windsor IoC Container (part of the Castle Project)

Digital Blasphemy - Windsor IoC Container in a Lunch Break

"This is the first post in what will (hopefully) be an occasional series on great tools that are found in many agile developers' toolbox.  The goal of this series is to provide a light introduction to a given technology all the way from the ground up to being able to use the tool in some limited fashion...all in the period of about an hour.  That said, this means that we'll likely be light on theory and edge cases of the tool allowing us to focus only on what we need to start using the tool and then showing you where to look when you need deeper answers.

Windsor is the Inversion of Control (IoC) container piece of the Castle Project, the same guys that bring you MonoRail.  In the short, IoC containers act as a holding structure for the components of your application allowing you to easily decouple them from one another.  This gives you the flexibility to refactor as necessary, replace live implementations of objects with mocked ones, and basically do whatever is necessary to get your system running well in the shortest amount of time.  Although we'll be talking about Windsor exclusively, you may want to check out other .Net IoC containers such as Spring.NET or Jeremy Miller's StructureMap.

..."

This is a short, lunch break length, example of using Castle to uncouple your components, to provide a method of switching out implementations as needed.

I've mention in the last that I've thought Windsor and the entire Castle Project looks pretty interesting. And this post just reinforces that...

(via DotNetKicks.com - Windsor IoC Container in a Lunch Break)