« Home | Rotor 247 » | Gilmor Gang - Longhorn Pillars » | Dan Bricklin Interview » | Intrusive Software » | Longhorn Transparency » | Anders and AOP » | Java Annotations » | Overly Pedantic » | Debugger.IsAttached » | Unhandled Exception Reporting »

The CRUDE Pattern

I'm currently working on the Authorization infrastructure for a software package in the finance industry. The approach taken is to use .NET attributes to declaratively state which user roles are authorized to perform the following actions:

  • read
  • write
  • create
  • delete
  • execute

These authorization attributes are placed on a .NET type, property or method. The user roles that are allowed/denied authorization are specified by role types listed in the attribute constructors. At runtime the infrastructure determines whether the currently logged in user can perform any of the specified actions and throws an exception if they can't and an attempt is made. An authentication subsystem defines the user and the roles they play in the system. It's the responsibility of the presentation layer to use this metadata to alter the user interface based on what the user is authorized to perform. Alterations include greyed out buttons/menus, panels/controls that aren't displayed etc.

While working on this functionality, I realized that the available authorization concepts that fell out of the requirements/design are most of the elements of the CRUD pattern:

  • Create
  • Read
  • Update
  • Delete

The exception was the addition of an Execute authorization concept. For a second, I considered renaming the AllowWrite and DenyWrite attributes to be called AllowUpdate and DenyUpdate. But then considering how professional the "CRUDE pattern" sounded, I decided against it .

Links to this post

Create a Link