Udi Dahan
Posts: 882
Nickname: udidahan
Registered: Nov, 2003
|
Udi Dahan is The Software Simplist
|
|
|
|
Travelling to IOC, and beyond
|
Posted: Apr 4, 2005 7:28 PM
|
|
|
This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
|
Original Post: Travelling to IOC, and beyond
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
|
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Udi Dahan
Latest Posts From Udi Dahan - The Software Simplist
|
|
One of the points raised in the comments to my previous post was that the method described would not be applicable for retrieving/consuming data/objects. Let's take as an example, that we want to populate the list of order items in a grid when an order is selected in the form. Before IOC, we would load our Order object and use the GetOrderItems method. The problem with this, among other things, is testing - our code is tightly coupled to the implementation of the Order class and the OrderItem class. For testing purposes, it would be most convenient if we could supply an instance of some other class; that way we could test the form in isolation. The next step in our journey would be to separate the interface of the Order class from its implementation so that the form would only need to be dependent on the interface. However, if the form did not have a reference to the concrete implementation of the interface, how could it instantiate the appropriate object in order to use it? Enter the IOC frameworks. They exist exactly to solve these kinds of problems. In our example, it would be the responsibility of the form to request the instance from the IOC framework, who would, in turn, instantiate the appropriate object and return it to the form. This opens up the opportunity to use mock objects to unit test our form. So far, so good. But it doesn't have to end there. One of the problems with this approach is that we aren't able to test the system without the UI - there's all sorts of workflow-ey type logic there, hiding behind button clicks and other abominations ;) A different approach might be used. Suppose that when the button is clicked on the form requesting that the order items be shown, all the form does is raise an event "OrderItemsRequested", no more. Well, that would get rid of the logic hiding behind the button, but that logic has to go somewhere. What we would need, also, is for someone to register for the event, so that it could be handled - someone that the form isn't aware of. Let's call this class Presenter, for now. In fact, it would be the Presenter which shows the form, in effect creating a new instance of the form class, and registering for the event. However, what I would much prefer is that the Presenter would just wire up the event of the form to the appropriate sink. However, events are not so aesthetically pleasing for receiving data - I wouldn't like seeing a delegate like: public delegate IList OrderItemsRequestedDelegate(); for the event above - it smells. However, what we could do is let the form dictate how it would like to get the data back, in essence letting the form influence the plumbing. The result of this would be a method on the form: public void SetOrderItems(IList orderItems); and a corresponding delegate: public void SetOrderItemsDelegate(IList orderItems); while the...
Read: Travelling to IOC, and beyond
|
|
Previous Topic
