Take the 2-minute tour ×

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.

share|improve this question
It would help your thoughts to take a good hard look at why Microsoft pushes people toward the use of Roles in .NET. (Like this article: msdn.microsoft.com/en-us/magazine/cc301838.aspx) –  John Fisher Nov 23 '11 at 0:50
@JohnFisher thanx for the tip. so would you suggest that i make the plans as roles? i mean that's how it seems to me right now, i haven't completely read the article yet. –  bool.dev Nov 23 '11 at 15:28
Actually, it would be better to define features of the plans (as Eli suggested). The .NET Roles would then map to the features. (Any one feature could be part of multiple plans.) If you create a whole new set of plans, the features will still exist and very little code would need to change. –  John Fisher Nov 23 '11 at 17:07
add comment

1 Answer

up vote 5 down vote accepted

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.

share|improve this answer
+1, thanks for the pointers. Yes, i agree the features have to be granular. and luckily they are not hierarchical either. i get the filter part too. where my doubt lies is if should i be spending time learning about RBAC and treat the plans as roles? you can see that @JohnFisher has stressed that i should read more about roles in his comment. –  bool.dev Nov 23 '11 at 15:24
add comment

Your Answer


