What is the best practice for .NET Application? Multiple exes or multiple forms?

Question

0.00/5 (No votes)

See more:

I've been looking a lot recently and I can not even find anything to lead me to the correct practice.
I have an application that has several "sub applications". I wonder if launch these sub applications as separate processes(exe files) and then have a controller that is responsible for listing, close, communicate (eg via IPC) these sub applications is a good practice?

Posted 29-Oct-14 8:43am

Demian__

Add a Solution

2 solutions

Solution 1

No, you should go with multiple forms instead.
Multiple exe's or dlls are rarely used which are independent in there functionality

Posted 29-Oct-14 8:52am

mehdimughal

Comments

Sergey Alexandrovich Kryukov 29-Oct-14 16:14pm

In many, of not most application, better answer would be: "none". Neither exes nor forms should not be multiple. I explained it in my answer.
Exclusions can takes place. It depends on the application goals. For example, my own mail client has two "main forms" behaving like having equal rights: one for sending, one for receiving.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-10-29T10:11:00

No way should it be "multiple exes". Those would be different processes. Processes are well isolated; there are given separate address spaces (if one process tries to use the same pointer, it points to a different physical memory address, this is the isolation supported by hardware, paged memory). Process are primarily designed for isolation, not for collaboration which would required such a bottleneck as IPC.

[EDIT]

More exactly, in some relatively rare cases, using "multiple exes" could be an acceptable option. Reluctantly, I used such techniques myself. For example, to run some command-line OS utility which is hard or impossible to write from scratch or through any accessible API. But "multiple exes" technique is not suitable as a regular/mainstream approach to modularization.

(Credit to the comment by C Pallini below.)

[END EDIT]

Of course, you can, and, in many cases, you should use multiple threads. They are not isolated and should communicate using thread synchronization primitives.

Now, how about separate forms? It depends on the application. For majority of applications, even multiple forms is not the best idea. Majority of best application uses one main form, and, inside this main form, there are controls (say, panels) which play the same role as your separate forms. Look at the docked UI of Visual Studio, for a typical example. Much simpler UI is based on the TabControl class (there are different classes for Forms and for WPF).

Above, I didn't mean modal (pop-up) forms. Of course, they are separate be definition and don't count. But, in a well-styled single-form application, even the number of those modal forms should be limited. Most operations should be "non-linear" (I borrowed this term from the field of video editors), which means that the user can control almost any aspect of the application at any moment, not in any predefined order (as in "wizards"). Modal forms prevent modifying any states on other forms until the modal form is closed, so use them sparingly.

—SA