Module Structure HELP!

Topics: Web Client Software Factory, UIP Application Block discussion
Jun 8, 2007 at 12:47 PM
I have really been around the houses with this one, so thought I would ask for other opinions! I'm trying to decide the best way to structure modules.

The application I'm developing comprises of about 10 modules. Some of these modules are simply a container for a few sub modules. I'm stuck in thinking whether I should create a module to cover all sub modules, or otherwise create a whole load of small modules and have them dependant on the parent.

As an overview the system is a back office for managing a store. There are various "top level" modules such as Cash (handling cash in tills, safe, balancing etc), Inventory (Products and stock), etc.

Take "Cash" for instance - this module comprises of balancing tills, doing a daily banking of funds in the safe, payments and receipts etc. All of these sub modules really only equate to a web page or two plus their relevant objects. They all interact with a back end "Cash" web service.

So either I can create a "Cash" business module and within it create a number of specific controllers and views in sub folders, or otherwise create a "Cash" module plus a "TillBalancing" modules, "ReceiptsAndPayouts" etc etc.

I'm sure this scenario has been encountered by most of you guys. I've had the same dilema on a previous project with the Composite UI block, but have never been certain on the best way of structuring this.

Any opinions would be gratefully appreciated!
Jun 9, 2007 at 12:29 PM
Hi Dave,
I am looking at a same kind of issue, and my current thinking on this is that it is much better to have sub-modules in seperate containers as it allows for loose coupling and a pattern for intergration n' changes (especially later on). Ofcourse, you need to evaluate it on a case-by-case basis, incase the components are uniquely intertwined or their development is lock-stepped then you may as well have them housed together.

Cheers