Application development with fully dynamic controls and processes based on database

Question

All software development projects are moving into separation of design, logic , data in patterns like MVC , MVVM and others.

Strangely i got a very strange requirement for a new software; that is :

It is required to have all controls/fields of the screen to be based in the database with their access rules which user is allowed to see which field or control

This is requested so the clients DB Admin be able to remove any field from the screen or change access level(view edit,none) of any field to a user!

I have suggested other ways of maintaining user access and roles, but the client is insisting of having everything each and every single screen control in the database to have full control on the software's screen content by their DB admin.

Is this way of maintaining screen and their content and controls in database has a name or is there a design pattern for that ?! i know doing the software in this will harm the client but can't provide enough justification for that.

My question is : Is doing software in the described way is recommended or not and why?

Answer 1

The way this is normally done is with user roles and a role access matrix.

Each user has a role, saved in the database along with the user name, password, etc.

Then, there is a two-dimensional role access matrix somewhere, specifying for each role and for each screen field what kind of access is to be had by users who have that specific role on that specific screen field. The access may be:

• "none", meaning that the field should not be shown to users of this role
• "read-only", meaning that the field should be displayed, but not be editable, and
• "read-write", meaning that the field should be displayed and editable.

In a variation of this scheme, each user can have multiple roles, so the access that a user has to a certain field is computed to be the maximum access permitted by any of the roles held by the user. When this variation is used, the 'roles' may be called 'groups', in the sense that a user may belong to several groups simultaneously.

In yet another, more sophisticated but even more complicated variation, we introduce permissions as an intermediate step, replacing the role-access matrix with a much smaller role-permission matrix. In this scenario, each field has a required permission for "read-only" access, and another required permission for "read-write" access. (These required permissions can be hard-coded for each field: they don't need to be configurable.) If a user has a role which has none of the required permissions, the user does not see the field at all. So, for example, an "email address" field may require some "view sensitive information" permission in order to have "read-only" access to it, and some "edit sensitive information" permission in order to have "read-write" access to it. Each user has or does not have these permissions depending on their role. Presumably there will be many fields that will require the same permissions for the same kind of access, so the total number of permissions will be very small, which in turn means that the role-permission matrix will be small.

So, one of these approaches should solve your problem nicely. In fact, I would be willing to bet that they more closely parallel what your client really wants to accomplish: they probably don't want to tailor the type of access of every single user to every single screen field, they probably have some user groups and possibly some field groups vaguely in mind, and they want different groups of users to have different types of access to different groups of fields.

The role-access matrix or the role-permission matrix can be stored in the database, or they can be stored in an external configuration file, or, if you are building your user interface using some scripting language like PHP, they can even be placed directly in the code, and let the customer modify the PHP source file to alter the permissions.

Answer 2

I have experience with big CRM/ERP product created this way. It is doable, but takes considerable more time and functionality will be limited. If this kind of thing is proposed only for access control, I don't think it's worth it.

Some downsides:

• All types of controls you want to use, must be custom coded to support persisting info into database. If it is more than couple types of text boxes, then your are looking at huge effort.
• Dependencies between controls are difficult to implement and will be limited in functionality.
• More difficult to debug and more complicated codebase.

I recomend you to fight harder with client and persuade him, that its a lot better to save only refference of controll to database. For example, you can add layer to your software, which prevents displaying control when its name was not found in DB and the same goal will be achieved.

Answer 3

First off, be aware of the Inner platform effect and do everything in your power to avoid it. Even if you do go the ultra-flexible route, the key to actually succeeding is ironically to fully understand its pitfalls.

However, if a platform of this flexibility is truly what is needed/what management knows it thinks it wants... at least avoid reinventing the DB inside the DB. Databases are dynamic and you application can create its own tables as well as examining their structures so avoid making massive key/value table. To do this, make a MetaRepository class that is responsible for creating/reading the table structures of your on the fly tables.

Usually having a business logic layer is a good idea, but here, it may just get in the way since adding any specific business logic for a dynamically generated entity may prove to be very difficult.

MVC is great, even if you have to use a dynamic view model. I have never seen a GUI application that does not benefit from MVC.

Getting back to your final question, DO EVERYTHING POSSIBLE TO AVOID GOING DOWN THIS ROUTE! There is already an application that can be configured to do anything you need it to... it's called a code compiler...

Answer 4

My client sells a case management system that works in exactly that way. All accesses to all fields are controllable. It is perfectly usable, although for performance reasons the permissions are cached in the application and updating the database would not have an immediate effect (but a rapid refresh mechanism could be implemented with triggers if required). I am sure there are many other products that work in a similar way.

To make it usable, you would want to structure the field permissions somehow - for example, grouping them into roles, as others have indicated.