How to instantiate DLLs to avoid indirect calls?

[Lou Arnold]

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?

I know exactly the problem that I'm trying to solve and I have tried to explain in as simple a manner as I could without bringing the months of research and trials that I have already been through. I can't do more. I don't see the point of sending code because I don't see an alternative to the structures that I have already explained.

[Lou Arnold]

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?

hahaha. I am trying to construct an architecture presented in figure 2 so that I can use re-usable code modules without writing a bunch of coupling code.

[TheGreatCthulhu]

You're not hearing me....

1st: Show me a DLL that does not contain static classes and that does not require instantiation.

Just pick any DLL (yours or 3rd party, it doesn't matter). For the 3rd time, I'm telling you (i.e. not asking questions): classes are instantiated, NOT DLLs! At least that word is not used for DLLs in the same sense it is used with classes.
Not on planet Earth.

When you write

SomeClass someVar = new SomeClass();

you're instantiating a Class, creating an instance (a.k.a. object) of SomeClass.
This class may be in the same assembly, or in a separate DLL, it doesn't matter. What's important is that this line of code DOES NOT "instantiate a DLL". A DLL is not the same thing as the class it contains.
As I've said, a DLL can (and almost always does) contain a multitude of classes? Think about it: how would you go about and "instantiate" such a DLL? It doesn't even make sense.
Classes can be instantiated, not DLLs!

Your problem most likely has to do with classes (and not DLLs), but you are expressing it (1) using the wrong terminology, and (2) in a rather vague way.

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.

I know that's your goal architecture. I'm just not sure what are you trying to say, and what the actual problem is, because of this: (1) the images you've drawn make sense for classes, but not for DLLs; and (2) why for the world do you think that the call stack depicted with the highlighted path (in my image) is direct, or any different form the path depicted in the diagram above?

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.

Well, Microsoft isn't perfect. As Arjay explained, assemblies can be dll-files or exe-files, they can even span across multiple files, or they can be created dynamically.

Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality.
[src]

But usually, and a DLL and an assembly can be thought of as one an the same. You have one assembly (an aplication - an exe file), using another assembly (a DLL).

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.

The issue here is terminology and some confused concepts.

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.

I would, if you only expressed your problem properly.
The thing is, it's hard for us to help you because:

• You're confusing some terminology and are not making much sense mixing DLLs and classes like that.
• Your concerns about indirection and reusability are too general; be more specific, tell us why is indirection bad in your particular case, what sort of reusability you want to achieve? Do you want to separate the UI from the data-domain logic? Do you want to be able to switch one implementation for the other, one class for the other? Do you need to layer your app? Do you want to be able to seamlessly replace one version of a layer for another? Do you wanna create a plugin? Do you want your app extensible? What?

Please re-read my previous post, and take good look at both this post and Arjay's reply following your last post. The only way we can talk is if we all use the same terminology - taking the same words to mean the same things.

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.

Well, show us the classes then - not necessarily in detail, but what are their names (especially if they are indicative of what they do), and how they are related. Maybe your overall design is bad.
The architecture you've shown just tells us "something references something to do something"? We can't draw a lot of conclusions from that. If we could see (maybe in a simplified diagram) what are the actual classes that interact, and what the dependencies are, maybe we could help. As long as you state what is it that you perceive as a problem, and why? What is the end goal that the current architecture is not good for?

But DLLs and MVC architectures per se are not the problem. Any OO program has this problem of Figure 1.

The thing is, we can't see the problem you're talking about in that picture. Sure - we see some relations, some calls, some indirections, some containment relationships, but - so what? The image itself doesn't tell in what way all that is preventing you to do whatever is it that you want done. I understand that the images are not equivalent, but that's only true if the DLLs in the picture are actually classes, and even then only in the conceptual sense, because implementation-wise (disregarding a few details) there is no much difference.
Maybe you're interpreting those images differently than us? Can you explain exactly what specific symbols represent, and specific relations among them?

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.

Of course it won't: you can't call an instance method without having an instance of the class. But, I repeat, instantiating a class is one thing, and instantiating" a DLL is nonsense.

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

So... what? Why is that a problem? The calling class (or more precisely, the calling object) can either (1) obtain a reference via the constructor, (2) create an instance internally or (3) obtain a reference via a method or a property. Than a method can be called on the object of the other class.
This is perfectly normal.
The design concerns here are related to how the objects interact, what are the relationships involved, and what are the other types referenced by the calling class.
These are the choices that make all the difference.

Finally, all I can say is: you'll have to be more specific. To reiterate what Arjay said: Forget DLLs - and forget assemblies, at least for the moment. Speak in terms of classes and tell us what exactly is it that you need to achieve, and why exactly you currently can't do it.

[Arjay]

hahaha. I am trying to construct an architecture presented in figure 2 so that I can use re-usable code modules without writing a bunch of coupling code.

It isn't clear on what is preventing you from doing that.

Understand that the closer you get to the UI, the more specific your code will be (and perhaps the less reusable).

You still can have reusability on each layer. For example, the UI could have reusable controls, or a common way to display errors. All this can be reusable on the UI layer.

The controller approach depends on the type of UI (since it needs to expose its data specific to the needs of the UI). If the UI is WPF, then the controller can be very general to support several ways to expose the data. So the controller could be reusable in this case for pretty much any WPF view.

Models are pretty easily made into reusable code.

Also, you need to consider the scope of reusability. Do you need to reuse only on an application level? Are you creating a library that is shared across apps, such as a UI component library, styles, etc?

Once you decide which layer the code goes and which parts of the code are to be reusable, then you can determine which assembly they need to go in, determine the namespaces to use, etc.

[Arjay]

Again we're trying to get you from moving away from the dll-centric view.

Essentially, here is the way the assemblies (dlls) are layed out in the process:

Process space
Exe (entry assembly)
MyDll1 (assembly1)
MyDll2 (assembly2)
MyDllN (assemblyN)
.NetDll1 (.NetAssembly1)
.NetDllN (.NetAssemblyN)
Native dlls

As you can see, the memory layout (omitting load addresses) of the assemblies have nothing to do with whether a form or a controller class calls into the assembly.

You control the dependencies of each layer putting the classes that are layer specific into an assembly that only contains classes for that layer.

Your model layer (and it's classes) should not have any dependencies on the controller or view layer. The controller layer should only have dependencies on the model layer, but not the view layer. The UI layer needs to reference the other two.

[Lou Arnold]

Again we're trying to get you from moving away from the dll-centric view.

Essentially, here is the way the assemblies (dlls) are layed out in the process:

Process space
Exe (entry assembly)
MyDll1 (assembly1)
MyDll2 (assembly2)
MyDllN (assemblyN)
.NetDll1 (.NetAssembly1)
.NetDllN (.NetAssemblyN)
Native dlls

As you can see, the memory layout (omitting load addresses) of the assemblies have nothing to do with whether a form or a controller class calls into the assembly.

You control the dependencies of each layer putting the classes that are layer specific into an assembly that only contains classes for that layer.

Your model layer (and it's classes) should not have any dependencies on the controller or view layer. The controller layer should only have dependencies on the model layer, but not the view layer. The UI layer needs to reference the other two.

Why don't you code it and see what happens.

[Arjay]

Why don't you code it and see what happens.

I just did and it worked fine. Too bad you can't articulate your problem.

[TheGreatCthulhu]

@Lou Arnold:
Wow! You just... Chose to ignore my post?!

That's too bad, because, maybe it may have helped you to get some things strait.
But since you're too arrogant to admit that the way you see and/or explain things might not be the best possible (no offense), and since there has been mention of MVC here, I'll provide you with some links, hoping that the articles they link to might somehow be able to help you.

First, MVC is written about everywhere, but often it's not presented properly, or it's mistaken for MVP. In its original form, MVC is not suitable for modern applications, Windows Forms included (because MVC assumes that the input comes trough the Controller, not the View, and because MVC granularity implies that there is a Controller-View pair for every single button, textbox, or other "widget"). MVP (Model-View-Presenter) is a variation that takes into account that in modern apps it is the UI (View) that receives user input events. This pattern is more coarse-grained. Now the whole Window can be a view. Further evolution leads to Fowler's Presentation Model, of wich MVVM is a WPF-centric variant. There's another, relatively new variant used specifically with Windows Forms, called MVP-VM (Model-View-Presenter - ViewModel).
Bottom line, for Windows Forms, you either go with MVP or MVP-VM, but make sure you have a really good understanding of the architecture, and the reasons behind it.

Twisting the MVC Triad - Model View Presenter (MVP) Design Pattern
Model View Presenter (MVP) Design Pattern with .NET - Winforms vs. ASP.NET Webforms
MVVM for .NET Winforms – MPV-VP (Model View Presenter - View Model) Introduction
Bonus: What granularity for MVC? - What exatly MVC is and where did it came from.

These are really great articles - I hope you find your answers there.