3

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?

Improve this question
2
  • Unless the functionality for each menu item is huge, it's more likely a class for each menu item, not an assembly. If you want pluggable technology you can try an Abstract Factory or IoC container, or just use Activator.CreateInstance to new up the relevant type. If you still want to use pluggable assemblies, have a look at MEF.
    – Robert Harvey
    Feb 10, 2016 at 15:37
  • @RobertHarvey Thanks for the suggestions. Indeed, some functionality will be huge, such as the picking logic. Others could definitely be implemented using a class. I'll do some research into the topics you suggested.
    – RianBattle
    Feb 10, 2016 at 15:41

1 Answer 1

Reset to default
3

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.

Improve this answer
2
  • Thank you for your suggestions...I'll take a step back, figure out everything that will eventually be added, and decide from there which route would best suit the needs of this project.
    – RianBattle
    Feb 11, 2016 at 13:32
  • 2
    @RianBattle: beware, figuring out everything that will eventually be added is exactly what often leads to the kind of overdesigning I mentioned above. Better focus on the things you know for sure they will be added. The road to hell is paved with good intentions ;-)
    – Doc Brown
    Feb 11, 2016 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.