“Best Practices” when designing large applications with multiple functions

Question

A little background first. I have been tasked with rewriting our gun software into VB.Net (converting the code from BBJ). This software incorporates many different inventory management functions, such as performing stock moves, stock inquiries, changing stock statuses, picking goods to put into cartons, and a multitude of other operations. I'm also relatively new to designing something of this scale from the ground up (more or less).

I have already developed a menu system, using a TreeView that is filled in dynamically based on the user's profile setup in our system (so that they may only access options available to their position).

My question comes into play when actually designing the software, and keeping the code for all the different menu items separate. Is it considered "good practice" to create a separate project for each menu item in a scenario like this? Most of the functionality is separate from each other (IE: the code for picking would not need to access the code for stock moves, and likewise the stock moves code would not need to access the directed putaway logic).

I'm trying to keep the solution as clean as possible, so that we don't run into things like one menu option having functions or resources named similarly to another, etc. And also be able to "plug in" new functionality as needed. The idea is that myself and one other programmer will mainly be working on this code, and I figured if we separate the code into projects, we can just include a project as a new function is completed, adding resources as necessary. Any recommendations?

Answer 1

If you map different menu items to

• the same function with different parameters

• different functions within the same class

• different classes within the same assembly, having a standard entry function

• different DLLs, each having a standard entry point defined by a special interface

• different executables, each having standard command line parameters

is fully up to you. All of those approaches can be designed "clean", without unneccessary code duplication, and configurable. I would just recommend to pick a solution having a level of abstraction which suits your needs (as abstract as it needs to be, but not more), and, if possible, choose one of the above strategies within one application system.

Be careful not to overdesign this by falling into the trap of the second system effect.