How to instantiate DLLs to avoid indirect calls?

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

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.

Quote:

---

Originally Posted by 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.

---

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.

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.

Quote:

---

Originally Posted by 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.

---

Do you have a working alternative architecture?

Quote:

---

Originally Posted by Lou Arnold

Do you have a working alternative architecture?

---

I'm puzzled by your previous question of:

Quote:

---

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.

Quote:

---

Originally Posted by Arjay

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.

Quote:

---

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.

Quote:

---

Originally Posted by Lou Arnold

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.

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.

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by Arjay

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.

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

Quote:

---

Originally Posted by Lou Arnold

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?

Quote:

---

Originally Posted by 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).

---

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.

Quote:

---

Originally Posted by Arjay

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.

Quote:

---

Originally Posted by Arjay

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.

:confused: You're not hearing me.... :mad:

Quote:

---

Originally Posted by Lou Arnold

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.

Quote:

---

Originally Posted by Lou Arnold

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?

Quote:

---

Originally Posted by Lou Arnold

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.

Quote:

---

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

Quote:

---

Originally Posted by Lou Arnold

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.

Quote:

---

Originally Posted by Lou Arnold

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.

Quote:

---

Originally Posted by Lou Arnold

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?

Quote:

---

Originally Posted by Lou Arnold

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?

Quote:

---

Originally Posted by Lou Arnold

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.

Quote:

---

Originally Posted by Lou Arnold

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

Quote:

---

Originally Posted by Lou Arnold

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.

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:

Code:

---

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.

Quote:

---

Originally Posted by 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:

Code:

---

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.

Quote:

---

Originally Posted by Lou Arnold

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.

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