How to instantiate DLLs to avoid indirect calls?

[Lou Arnold]

Forget DLLs. And forget Assemblies (which are what the binaries are called in .Net - which can be dlls or exes).

Your Controller and Model code can reside whereever. It doesn't matter where this code resides, but the important thing is the View (Forms) code is decoupled from the business logic(M & C code).

The controller and model code can fit inside the main forms application assembly or in some other assembly.

If you go with the MVC approach, you typically create one instance of the Controller class (which manages a Model instance) and connect the View (i.e. forms) to that one instance.

That can be accomplished by passing a controller reference to each form or make the Controller class a singleton.

The controller class (single instance) is going to control the creation and destruction of any other classes used within the controller and perform operations on the model class (which in turn handles any creation of objects inside itself).

The controller class provides properties, methods, and events that the View (Forms) ties into. If possible, data binding can be used to tie the View and the Controller together (especially in the WPF world).

1) I'm not working in WPF; whatever was written for that doesn't apply.
2) I read and looked at code that implements MVC in MS Windows Forms; it winds up with the same problem. Its the need to pass references that kills it. For when you have a LogManagerclass and a DateTimeFormatter Class and you need to call these from the Forms Class and from within several other classes, the reference passing falls apart. One can make it work, but then the coupling would be so great that you would no longer have re-usable modules.