CODEWITHSUNDEEP
c#winforms
NoChance
NoChance

Reputation: 5752

Handling complexity and size of winforms with about 100 forms

I am at the design stage of a Winforms application that might have about 100 separate forms. Security is not a concern. The application may access a local database. No LAN or networking is required. Each form may launch sub-forms. Each main form represent 1 business function. The forms will be launched from 1 master form. I was thinking of having each form as a separate .exe and exchange data (most data exchanged is less than 10Ks) using temporary files. This way, each form can be built separately instead of embedding all the forms into the master form.

I am sure there are more complex applications and much better architecture, your help is appreciated.

The question here is: What is the best simple way to architect an application with so many forms without having all the forms in 1 project or is that OK memory wise and performance wise?

Note: Of course I am not looking for code, an idea or a reference will suffice. Thanks.

Upvotes: 0

Views: 178

Answers (2)

Ronan Thibaudau
Ronan Thibaudau

Reputation: 3603

The simple answer is yes, it is ok to have 100 of forms in the same project, nothing special about that, it will also be faster to compile than tons of mini projects containing a few forms as C# compilation is very fast but having dependencies (or worse, nested dependencies) involves writing a lot to the disk (compile dll C, write it in output folder C, compile DLL B that depends on B, copy C to B folder, then compile project A that depends on B, and have it copy B.dll and C.dll to A etc etc).

It's impossible to tell you how to properly architect your solution without a LOT more information but on your specific question there is no reason to split your project just because it has a lot of form, nothing bad will happen as a result of it.

Upvotes: 1

Gregor Primar
Gregor Primar

Reputation: 6805

Separating funcitionalities into multiple standalone apps (exe) and sharing temp files is a realy bad idea. There are limited scenarios that can benifit from this approach and I have a clue that your scenario is not one of them.

There are more better ways to share data between apps than sharing temporary files (WCF, .NET Remoting, MSMQ, Web Services, ...). You can imagine that running 100 exe apps will also burn a lot more resources that single one app with same functionalities. Your approch is also prone to file locking so be adviced to reconsider your solution.

Upvotes: 1

Related Questions