I\'m currently developing a web application, that provides some \'service\' to t

Question

I'm currently developing a web application, that provides some 'service' to the user. The user will have to select a 'plan' according to which she/he will be allowed to perform application specific actions but up to a limit defined by the plan.
A Plan will also limit access to certain features, which will not be available at all for some plans.

As an example : say there are 3 plans, 2 actions throughout the application

users in plan-1 can perform action-1 3 times, and they can't perform action-2 at all
users in plan-2 can perform action-1 10 times, action-2 5 times
users in plan-3 can perform action-1 20 times, action-2 10 times
So I am looking for the best way to get this done, and my main concerns besides implementing it, are the following(in no particular order)

maintainability/changeability : the number of plans, and type of features/actions will change in the final product
industry standard/best practice : for future readiness
efficiency : of course, I want fast code!!
I have never done anything like this before, so I have no clue about how do I go about implementing these functionalities. Any tips/guides/patterns/resources/examples?
I've read a little about ACL, RBAC, are they the patterns that I need to follow?
Really, any sort of feedback will help.

Explanation / Answer

In my own experience, this can really turn into a maintenance nightmare as things change - the maintainability will be the main issue.

I wouldn't worry too much about optimization - leave that for late in the game, as the code to filter features shouldn't run any slower than any of your other code - not likely to become a bottleneck.

For maintainability, I have a few pointers:

Build one program with a lot of switches.

Keep all feature availability as granular as possible, with each feature able to be disabled individually. You can then build the plans as filters to decide what features are disabled, but that logic is separate and laid on top.

In the program, you should always be checking if the feature is available (simple yes/no) and NEVER if any particular plan is available. So, feature availability is determined at run time by a boolean list for the current account, and the list is set at some point based on the plan selected, but the plan and the feature checks are NEVER crossed - each stays on it's own side of the list.

If possible, block feature access as early/macro as possible. For example, if a feature occupies a few lines of code on a controller/class, it's sort of a pain in the butt to maintain. If it occupies a full "page" of the site (however that breaks down in your architecture) it's much easier to block access (with page level privileges), or even access to a 'section' however that breaks down. That way, you're just blocking access to part of the site, rather than showing a different page with almost-the-same functionality to different users, which is less maintainable.

Try, again if possible, to avoid feature hierarchies, since you won't want to have to worry about access to sub features and that kind of thing.

Also, if possible, try not to have your features overlap. Keep the lines between features as crisp as possible, so you don't end up disentangling them later with one switched off, but oh, wait, we need part of it.

This doesn't mean you can't have a clump of functionality considered a single feature, just make sure you will NEVER want to break itapart. If there is any doubt, then make them multiple features.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.