Building presentation layer directly on data layer

I personally prefer loosely coupled layers my code. In your case, I would have few interfaces with my implementation. However, I would also like to provide an opportunity to consumers to play around with certain things.

So, I would start with interfaces that provide data to my graph. Assuming it uses data coming in from a database, I could use a database layer that works with IDbConnection and other such interfaces. Now, I can support anything that has a provider that uses these interfaces.

Next is processing. Once data is available we need a generic way to pass it around. So, think of some more interfaces that help you do that. And your Model (class whose instance would represent data) must implement it. This enables adding and removing business rules easily.

Now, the appearance. For controls, I prefer using public events with a default handler embedded in the control itself along with properties. For instance. on click a bar in bar chart, it's color should become say red. Now a consumer likes green, so, give a property for him to do it. He also wants a tool tip and some more details on mouse hover. So, give him a event to handle.

I understand this is way too generic and hope it is at least somewhat helpful.

The context of your application decides everything.

To illustrate why this is true, let us first start with the purpose for inversion of control or IOC. The purposes behind IOC are extensibility and horizontal scaling.

In extensibility, the application needs to decide what implementation to use under a particular set of circumstances. For example, if the user chooses to pay via PayPal, it needs to choose the PayPalPaymentProvider implementation rather than the Authorize.NET implementation.

For horizontal scaling, the implementation is decoupled from the application code so that you can easily scale up by writing new implementations and setting those within the context of your application. For example, if my application currently uses MySql, but I'm now to the point where MySql isn't performing well because my application has become too popular, using IOC I can simply write a new database implementation that is SQL specific and throw out the MySql code without having to change any application logic at all.

All of that being said, let's add the fact the presentation layer is nearly always tied to a specific environment that it needs to run under. Unless you either write your own application host or OS or you abstract your entire UI into its own project that is then hosted by a context project, the project that contains your UI IS going to be the decision maker for everything implementation related.

Now, to answer your question. You do not need to have a reference to the DIApplication.Data project in your DIApplication.Webservices or DIApplication.Winforms projects and you don't want to reference it directly because then it defeats the purpose of using the IOC. However, you will need to copy the dll for DIApplication.Data into the context of your applications so that it can read the assembly. Defining what implementation you want to use for the IOC in the web.config and app.config is good practice.

However, for the IOC to be able to read and instantiate the concrete implementation, it must be able to find it. The idea here is that you could swap out that dll with a different concrete implementation, change the configuration file to point to the new concrete instance and everything would continue to work without needing to rebuild the application at all, much less having to change any code.

So, to summarize the answer, all you should really need to do at this point is use a post-build action to copy the concrete implementation into the bin folders for your Windows Forms and Web applications.