We’re currently developing a new piece of hand-held software. I cant discuss the nature of the application, so I’ll use an example instead.
We’re designing hand-held software for managing a school. We want to modularise each aspect of the system so that different schools can use different features.
Our system will start with a main menu and a login screen. I’d like this to be the base of the system and be where the modules will be added to. I.e. I’ll have a project called SchoolPda.
I then want to have different modules. I.e., I want a registration module that will handle student registrations. I want a classroom module for managing classroom cleanliness, etc.
The way I’d possibly see this working is including/not including different dlls and having the base system’s main menu expose buttons to access those modules if the dlls exist. That’s just the kind of thing we’re after.
Does anyone have any experience doing something like this? What would be the best way of doing it? We don’t need to worry about the database as the database will always be the full database, but aspects wont get populated if the associated modules do not exist.
I have been in projects that have done it two ways:
In one project we did not deploy certain DLLs if the customers weren’t licensed. That’s what you are suggesting. It worked fine. Of course, there was no way to enable those modules without an additional install, but it made perfect sense for that app.
In another project we deployed everything and only exposed to the end-users the menus, buttons, etc. for which the customer was licensed. We did that because then the user could easily add-on an extra module by adding a license for it. When the license was added, the stuff magically showed up on next login.
So in my experience, I would say look at your licensing model as one big piece of your decision. Think about whether you would ever want to add those extra modules on the fly.