OT: Need advice for building large applications.

[Visual Systems AB \(Martin Arvidsson\)]

Hi!

I have newly began to write applications in C#. Now i am going to build a
large scale application in C# (A large business system)...

This system includes a lot of forms.

Questions...

1. Should i include all the forms in the Executable file?
2. Should i split up forms and put in DLL's. If so how to comunicate and
where to get good info?

3. Should all the common functions be in separate .DLL's?

Any information, links so forth, would be greatly appreciated.

Regards

Martin Arvidsson, Visual Systems AB, Sweden

 

[Guest]

Hi,

Actually your question is totally related to Software design, there are
plenty of books around about OO design.

Some tips:
-Encapsulate your objects according their nature, it doesn't matter if they
are forms , they are always objects
Example:
You can have a class called Customer, put your method related to customers
on this class, ex: Get() , Update(), etc.

-Separete in different DLLs if you don't need to load them all the time,
this will save you loading time and memory, ie: if you have a function to
mantain the system they are not necessary to be loaded when you start the
app, so you create an instance of your DLL when you needed only, and you can
dispose it when you are finish.

-Separete your presentation layer from your business layer, this will allow
you to reuse your code, your form will be in a different class as your BL. If
you have a form that shows customers this should use the Customer class to
get the functionality, so you can use your method "Search()" in other forms
as well.

This is the minimum tips, but a good advice is to get some books or search
on the net for OO design, it doesn't matter the lenguage actually.

hope this helps
Salva

 

[Guest]

On your comment on loading and disposing of a DLL you mean loading it through
a different app domain so that you can unload it? From what I understand is
that once you load a dll from your c# app you can't unload it unless you have
loaded it within a different app domain. Is this correct?

 

[Guest]

Hi,

A DLL is an object, when you request to load it the OS will assign you
blocks of 64Kb for your application extension. Your extension will be loaded
on the heap. If you dispose your object (supposing that you dispose correctly
and no other object is referencing it) your object will be available for the
next Garbage collection, the memory assigned will be returned to the free
memory pool. You can easily check this usin the CLR Profiler to check your
heap. You can force the collection using GC.Collect.

Best regards
Salva

 

[Guest]

You mind posting a quick example of how I would dynamically load a dll and
dispose of it? Thanks.

 

[Guest]

The reason I ask is that when ever I looked for samples on how to dynamically
load a c# dll I would find responses such as the following:


Actually you can do this. You will need to look into crating new
application domains (via System.AppDomain.CreateDomain), using
reflection to load the dll that you are interested in (see the
System.Reflection namespace), then unloading the AppDomain when you are
done with the dll (using System.AppDomain.Unload).

If you are interested in seeing an "in production" working example of an
application that can do this, take a look at NUnit. NUnit allows you to
replace the test DLLs at runtime and the application will unload the
ones it was using then load up the new ones.

Hope this gets you going in the right direction.

Have A Better One!

John M Deal, MCP
Necessity Software

Hello Daniel,

You can't do that.

 

[Guest]

Hi Robert,

I think here are two different things, one thing is to load and unload DLLs
"unbound" or dynamically is correct to use reflection (to simulate the old
CreateObject of VB). The advantage is that you can upgrade your DLL without
signature but you have to discover the methods and is quite a pain because of
the boxing and unboxing operations.

The topic that I was discussing is about "bound" dlls, if you have an app
with 200 Dlls they are not loaded when you start the app, they are loaded
when you create the first object of it, you can try this using the CLR
profiler. What I was saying is when the last object is disposed the memory
extension that the DLL was using is available for the garbage collection. So,
my point was that if you granulate your application you can load on demand,
when you need it only. If you have everything in a single assembly the full
memory range is requested to the OS.

Hope this solve the confusion,
best regards
Salva