Effective use of a DLL

Up until now I've only used DLL's as a source for plugins in my applications.

But I know that using DLL's will allow me to update my program "client side" a lot easier the re-downloading the main EXE all time.

The problem is, I cant seem to find an effective way to use dll's in my application, or to use them in a way that would impact the program, but not force me to change the way the entire program works.

The "application" in this instance is an XNA Game.

So for example, I have three main classes (excluding the main game Class)

Units Players Networking.

I would like to have the Units/Players in one DLL, and the Networking in another DLL, or at least move the networking to a separate DLL, But the way the networking class works and is coded would require the DLL to have a reference to the Game, and the Game to have a reference to the DLL, which is prevented in Visual Studio to prevent circular dependencies.

My question, is how can I effectively use a DLL to store my networking class, I have a couple of ideas, but I'm not sure how feasible any of them is yet.

What I would like, if possible, would be to have the entire networking instance running from the dll, sending receiving, and updating the game data as needed.

But so far I have only been able to come up with a way to have the receiving and sending in the Main game.exe and move the handling functions into the dll, and even then, the handling functions cannot (easily) communicate with the game.

I also thought of using the Plugin System, but that requires me to use Delegates for all my funct开发者_如何学JAVAions that I want to use in the Networking DLL, and seems very inefficient in the long run.

If this sort of thing cant be done with DLL's (back and forth communication between the Host program and dll), then what use are they anyway?

Sure I can have simple functions, like my "Color" class, to parse and return color codes, but simple things aren't going to change, and need to be updated.

Anyway, I always tend to ramble about things that don't matter (for the most part), so thanks for taking a look, and for any responses :)

OK - so you have 3 classes with dependencies on each other.

Can you change the relationship so that instead of one class referencing another, instead you reference an interface?

E.g. ClassA has a method which uses ClassB - MethodB1 ClassB implements interface IB, so now Class A has instead a reference to IB

Put all your interfaces in a separate assembly. Now A, B and C have no reference to each other - just to the interface class. In your executable use Dependency Injection to wire up the Concrete class implementations.

Actually, not using DLLs simplifies things a great deal. In this age of fast downloads I would rather update a program by downloading a single executable, rather than a bunch of DLLs that often get installed in distinctly dubious locations.

Usually DLLs are just a product of having more projects in a solution.

So the question you are asking is:

"Why and how would I have more projects in my solution?"

It boils down to organization of source code.

In OOP objects usually can be grouped into smaller domains that can be described by themselves and work as a black-box.

These blackboxes are DLLs.

In a game I can think of a few separate projects:

• base classes
• game logic
• renderer
• serialization/deserialization (save manager)
• audio manager
• code utilities ...

So if you can organize your code to work in that way you can have DLLs.

You can't have them without reorganizing what you have.

If the APP is coded in a very monolithic way then you could have troubles in separating logical domains of code.