Question

I am working on an ASP.NET WebForms project, and we need the ability to configure behavior throughout the application based on the current user’s “group”. This applies to almost all aspects of the application, including site navigation, showing/hiding certain user controls on pages, and executing custom business logic in some cases. However, the vast majority of the application behavior is shared among groups, so we’ve ruled out the idea of creating entirely separate apps.

Essentially, what I’m looking for is an architectural approach to implementing custom behavior in an ASP.NET WebForms application. Is there a better approach than sprinkling if/else statements throughout the code base in the view layer, the business layer, and the persistence layer?

Edit: Some examples:

• If a user in in Group A, their
  navigation will consist of all
  navigation from Group B plus a few
  additional links.

• If a user is in Group A, a page will
  show user controls c1, c2, and c3.
  If the user is in Group B, they will
  only see c1 and c3 on the same page.

• If a user saves some data on a form
  and they are in Group A, send a
  notification email. If the user is
  in Group B, send a text message
  instead.

We can solve all of these specific problems, but are looking for a way to encapsulate this behavior as much as possible so it’s not scattered across the code base.

Edit: There are some interesting answers related to dynamically loading user controls. Should the logic to determine which controls to load or which behavior to use based on the user’s group be encapsulated in one (non-cohesive) class, e.g.:

GroupManager.GetNavigationControl(int groupId) // loads site nav control based on group
GroupManager.PerformNotification(int groupId) // sends text or email based on group

Or should this logic exist as close as possible to the location in code where it is used, and therefore be spread across the different layers of the code base?

Answer 1

Well there’s not a ton of details to go on here, but I would suspect you might benefit from polymorphism (i.e. various interface implementations) to deal with the parts of the application that differ between user groups. An Inversion of Control container like Spring.NET can help you wire up/configure these various implementations together based on the current user role. You might also benefit from Spring’s Aspect Oriented Programming API in which you can decorate methods in your business layer/data access layer so that authorization logic can be executed.