How to instantiate DLLs to avoid indirect calls?

[Lou Arnold]

I have a problem with building and using DLLs. I have built several to be used in a Windows Application, but basic enough to be re-usable. The problem is that they have to be instantiated and that means indirect calls to nested DLLs. Isn't there a better way?

I have attached a diagram. In Figure 1 boxes represent classes: A Windows main form, a subform inside the main form, DLL1 and DLL3 instantiated inside the main form, adn DLL2 instantiated inside DLL2. Now...for the subform to call something in DLL2 is pretty messy, and getting from DLL2 to DLL3 is tougher still, because if I have to code indirection, then the DLLs are pretty well cutomized to the architecture, and that doesn't let them be re-usable.

What I want is an architecture more like Figure 2: the subform is still inside the main form, but the DLLS are "outside" and can be called directly from the forms application and from one DLL to another (via interfaces). But where does one instantiate these DLLs? and their interfaces? (Static classes can't inherit interfaces, so that idea is out.)

[TheGreatCthulhu]

Um... What you mean by "DLL1 and DLL3 instantiated inside the main form" and "nested DLLs". Are you loading the DLLs dynamically?

You don't instantiate DLLs - they are libraries of classes. You instantiate classes within. The way DLLs work, it's allready as in figure 2. The less interdependencies they have, the more reusable they are, but you can't eliminate all of the interrelations.

[Lou Arnold]

Um... What you mean by "DLL1 and DLL3 instantiated inside the main form" and "nested DLLs". Are you loading the DLLs dynamically?

You don't instantiate DLLs - they are libraries of classes. You instantiate classes within. The way DLLs work, it's allready as in figure 2. The less interdependencies they have, the more reusable they are, but you can't eliminate all of the interrelations.

I should have stated things more clearly. I am using VC# 2010 Express and dotNet V4. When I say DLL, I mean a class library, aka assembly in dotNet speak. And, no, they are not already in the architecture of figure 2, but rather of figure 1. I know because I created them.

Yes, they are being loaded dynamically, but not via explicit Win32 calls. They get loaded either when I instantiate them or when I first call one of their methods. I am not talking about services either. The class library file has a class defintion (and an interface defintions for some classes). There is only ever one instance of each class, but they are not singletons. They are intended only to provide general purpose functions that should really be accessible to most other classes.

However, you may have devised a way of creating DLL in the way of Figure 2. If so I would like to hear how you do it.

[Arjay]

I think you are making a mistake by thinking in terms of dlls.

Instead, think about things in terms of class design and what class hierarchy that makes sense (if any).

Then look to where to put (i.e. which assemblies) the classes should go in.

Also, look at using a design pattern to separate the UI components (forms, controls, etc.) from the business logic. Check out MVC, MVVM design patterns.

Using these design patterns isn't necessarily that popular in WinForms; however, in WPF using a pattern such as MVVM is the way to go.

Once you organize your code into a pattern such as MVVM, determining which assemblies the individual classes go will be obvious.

[Lou Arnold]

I think you are making a mistake by thinking in terms of dlls.

Instead, think about things in terms of class design and what class hierarchy that makes sense (if any).

Then look to where to put (i.e. which assemblies) the classes should go in.

Also, look at using a design pattern to separate the UI components (forms, controls, etc.) from the business logic. Check out MVC, MVVM design patterns.

Using these design patterns isn't necessarily that popular in WinForms; however, in WPF using a pattern such as MVVM is the way to go.

Once you organize your code into a pattern such as MVVM, determining which assemblies the individual classes go will be obvious.

Do you have a working alternative architecture?

[Arjay]

Do you have a working alternative architecture?

I'm puzzled by your previous question of:

But where does one instantiate these DLLs?

The developer doesn't have to instanciate the DLLs, all they have to do is create the class that is located inside an assembly and the framework will load the assembly.

[Lou Arnold]

I'm puzzled by your previous question of:

The developer doesn't have to instanciate the DLLs, all they have to do is create the class that is located inside an assembly and the framework will load the assembly.

Are you talking about a static class/DLL? I have never programmed one so you might be correct in terms of accessing its methods, but I know that static classes cannot inherit anything and that eliminates interfaces.

If you are talking about a dynamic class, then to access a method in the class, one must instantiate it, and "Add reference" to the class library assembly. Otherwise the linker will not see any method in the class library. Once the program is started the DLL is loaded at the first call to a method in the class. Other dot Net asseemblies are handled the same way, I assume.

The Windows Form class appears to be the only class in which to instantiate any other class - whether in a class library or in a code file that is part of the main project itself. Any OO program has this problem: there is the main program and the rest are classes that must be instantiated in the main program. I can't see another alternative, because I am stuck with the Windows App Form class.

In fact, the only other alternative I see is to take all the methods from all the class libraries and put them into the one Forms class and that eliminates the re-usable code idea. But other Windows Forms Apps developers must be experiencing this same problem for anything beyond the simplest Apps. I wonder how they handle it the re-usable code problem, without simply carving up pieces of other programs and lumping them all together in the the next program.

[darwen]

Any OO program has this problem: there is the main program and the rest are classes that must be instantiated in the main program. I can't see another alternative, because I am stuck with the Windows App Form class.

You can create class instances in the main function (in Program.cs) and pass them into your main form.

Your main form can then execute methods on the 'Application' class instance which is passed in and which can be defined in any other assembly.

Bear in mind it's a good idea to not have any UI specific references in your class libraries - they should be data only if you want true reusability.

Darwen.

[Arjay]

In fact, the only other alternative I see is to take all the methods from all the class libraries and put them into the one Forms class and that eliminates the re-usable code idea. But other Windows Forms Apps developers must be experiencing this same problem for anything beyond the simplest Apps. I wonder how they handle it the re-usable code problem, without simply carving up pieces of other programs and lumping them all together in the the next program.

I've answered this already. Do a bing or google search for MVC or MVVM design patterns. The goal of these design patterns is to decouple the data/business logic from the UI.

When you implement this pattern your data and business logic code goes into assemblies and the WinForms interact with the 'controller' part of the code (using the MVC pattern). The UI and the controller use binding to form the connection between the two.

Since the business code is separated from the UI, the dev can connect the business code to different UI's (different forms, controls, etc.).

Other benefits are that since the business code isn't tightly coupled to the UI, it can be reused in other project, unit tested and so on.

[TheGreatCthulhu]

I think I know what's going on here: Lou Arnold, I believe you're confusing some concepts...
Let me try to explain.

A DLL (dynamically linked library) or a class library is a library of classes - a toolbox of sorts - that contains compiled class definitions, and maybe some other types. Note that I used plural - in the majority of cases there are multiple classes defined within; a DLL with a single class is not very useful.

Are you creating a separate DLL for each of the classes? With one class per DLL?
If so, than your approach is wrong. DLLs aren't the primary aspect of your application architecture - they are just a way to deploy your classes. They usually contain a set of related classes and other types (structs, enums...), that are intended to be used in a specific problem domain. For example, take the classes you probably use all the time, like Button, Label, TextBox, Panel, or Form: they are all, together with a bunch of other classes, packed into the System.Windows.Forms.dll (within the System.Windows.Forms namespace, but that's a completely different thing). This DLL is automatically referenced by a Windows Forms project. All the classes provided by the .NET framework are distributed across various DLLs.
DLLs are not influencing the logical architecture of your application; rather, they are a way to physically organize your code.
As such, they are never instantiated; DLLs do not have instances in the sense classes do.
DLLs just provide class definitions; your project than references and loads the DLL so that your code can be aware of these classes. The classes are then instantiated - you create an object of a specific class - and the DLL has nothing to do with it. To your code, it doesn't make any difference where that class is defined; as long as the code "knows" about it, it can be in the separate assembly, or in the same - it doesn't make any difference to the logical structure of your application.
The reusability the DLLs provide stem from the fact that the classes they provide (and thus their functionality) can be used by several different applications.

With that cleared, let's go back to your original concern about the indirections. Assuming that that what you labeled in your image as DLLs are actually classes (but it doesn't really matter as far as indirections are concerned), note that the logical concept of containment and of simple association are not really distinguished in the language syntax. In both cases you implement them using a member field.
So, the level of indirection is the same in both of your pictures - take a look at the modified version I attached: the highlighted path in the lower image is the same as the the one depicted above it.
With all that in mind, can you explain in more detail what kind of reusability you're aiming for, maybe we can propose a better design.

[Lou Arnold]

I think I know what's going on here: Lou Arnold, I believe you're confusing some concepts...
Let me try to explain.

A DLL (dynamically linked library) or a class library is a library of classes - a toolbox of sorts - that contains compiled class definitions, and maybe some other types. Note that I used plural - in the majority of cases there are multiple classes defined within; a DLL with a single class is not very useful.

Are you creating a separate DLL for each of the classes? With one class per DLL?
If so, than your approach is wrong. DLLs aren't the primary aspect of your application architecture - they are just a way to deploy your classes. They usually contain a set of related classes and other types (structs, enums...), that are intended to be used in a specific problem domain. For example, take the classes you probably use all the time, like Button, Label, TextBox, Panel, or Form: they are all, together with a bunch of other classes, packed into the System.Windows.Forms.dll (within the System.Windows.Forms namespace, but that's a completely different thing). This DLL is automatically referenced by a Windows Forms project. All the classes provided by the .NET framework are distributed across various DLLs.
DLLs are not influencing the logical architecture of your application; rather, they are a way to physically organize your code.
As such, they are never instantiated; DLLs do not have instances in the sense classes do.
DLLs just provide class definitions; your project than references and loads the DLL so that your code can be aware of these classes. The classes are then instantiated - you create an object of a specific class - and the DLL has nothing to do with it. To your code, it doesn't make any difference where that class is defined; as long as the code "knows" about it, it can be in the separate assembly, or in the same - it doesn't make any difference to the logical structure of your application.
The reusability the DLLs provide stem from the fact that the classes they provide (and thus their functionality) can be used by several different applications.

With that cleared, let's go back to your original concern about the indirections. Assuming that that what you labeled in your image as DLLs are actually classes (but it doesn't really matter as far as indirections are concerned), note that the logical concept of containment and of simple association are not really distinguished in the language syntax. In both cases you implement them using a member field.
So, the level of indirection is the same in both of your pictures - take a look at the modified version I attached: the highlighted path in the lower image is the same as the the one depicted above it.
With all that in mind, can you explain in more detail what kind of reusability you're aiming for, maybe we can propose a better design.

1st: Show me a DLL that does not contain static classes and that does not require instantiation.
2nd the two figures are not equivalent. In the 2nd figure the (ideal) linker has linked all calls outside the instance of the Forms class and the (single) classes in the DLLs to methods in other DLLs. In a sense, Figure 2 presumes that the DLLs are either not instantiated or instantiated in some location that I am not aware is possible. Regardless, the calls in Figure 2 are all direct. Let me state again that this is the goal architecture and not a factual one.
3rd. Microsoft uses both the terms DLL and assembly interchangeably. They cite this method as a way of writing re-usable code. And it works.
4th: I can put anything into a DLL so long as its compiles separately; convention is not an issue here. Again. this would seem to be a problem for any OO program that attempts to use re-usable code, not just MS Windows and not just dotNet and not just with DLLs.

Most important. I am writing in MS Visual Studio, and Windows Forms classes have a fixed architecture. Whatever you suggest has to fit into that. Stick to practical discussion.

[Lou Arnold]

I've answered this already. Do a bing or google search for MVC or MVVM design patterns. The goal of these design patterns is to decouple the data/business logic from the UI.

When you implement this pattern your data and business logic code goes into assemblies and the WinForms interact with the 'controller' part of the code (using the MVC pattern). The UI and the controller use binding to form the connection between the two.

Since the business code is separated from the UI, the dev can connect the business code to different UI's (different forms, controls, etc.).

Other benefits are that since the business code isn't tightly coupled to the UI, it can be reused in other project, unit tested and so on.

I know about MVC! The entire point behind the DLLs was to separate the Model code from the integrated View-Controller code that is in the Forms class. Its connecting the business code that's the problem and the fact that parts of the UI are in different classes is also a problem.
But DLLs and MVC architectures per se are not the problem. Any OO program has this problem of Figure 1. I tried to make that point in my last post.
Try this:
- Create a Windows Forms App project. Create classes in the same project - without DLLs The goal is to call from one class to a method in the other class. Try to do that without instantiating the classes; it won't work.
- Then instantiate them in the Forms class. From one class, try to call a public method in another class. You will need to pass a reference of the class being called to the instance of the calling class when the calling class is instantiated.
- This is the same situation for any OO style of program - its not specific to MS Windows Applications. And so others must have (had) this problem as well.

[Arjay]

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).

[Arjay]

1st: Show me a DLL that does not contain static classes and that does not require instantiation.
2nd the two figures are not equivalent. In the 2nd figure the (ideal) linker has linked all calls outside the instance of the Forms class and the (single) classes in the DLLs to methods in other DLLs. In a sense, Figure 2 presumes that the DLLs are either not instantiated or instantiated in some location that I am not aware is possible. Regardless, the calls in Figure 2 are all direct. Let me state again that this is the goal architecture and not a factual one.
3rd. Microsoft uses both the terms DLL and assembly interchangeably. They cite this method as a way of writing re-usable code. And it works.
4th: I can put anything into a DLL so long as its compiles separately; convention is not an issue here. Again. this would seem to be a problem for any OO program that attempts to use re-usable code, not just MS Windows and not just dotNet and not just with DLLs.

Most important. I am writing in MS Visual Studio, and Windows Forms classes have a fixed architecture. Whatever you suggest has to fit into that. Stick to practical discussion.

At this time, I'm not sure the point of your post.

What problem are you looking to solve? Having to instantiate a non-static class before using it? What exactly?

[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.