Java – Allowing users to add their own custom fields in a Spring MVC Hibernate application – What’s an ideal approach

hibernatejavajpaspringspring-mvc

We all may have seen applications like JIRA, or many CRM or other applications that allow its users to define their own custom fields to an entity, and do a variety of stuff with it, like making them mandatory, validate their values and so on.

I want to do just that in the Product we are creating.

Let's assume our product allows a user to create his/her own Project. A project has pre-defined attributes such as

Name (String)
Description (CLOB)
Type (String)
Owner (String)
Status (String)

Now, as a user, I would like to add the following custom field to my project

Due Date (Date)

Ideally he should be able to create a custom field in my product which would capture the following details:

Name of the field
Type of the field
Default Value
List of values (if the field is to be a drop down list)
Mandatory or not

Similarly, I would like to allow this feature of adding custom attributes not only to a project, but to a few other entities as well.

This is the technology stack we're using and so far we're pretty ok with it.

Spring MVC, JSP and jQuery as the Web Framework and for the Views
JPA with Hibernate for persistence
Oracle, MS SQL, MySQL – Currently our product works on these
databases.

How do I approach this requirement? I would like to be educated on the following:

How to I decide the best data model for this? Do I add a separate table for custom field definitions, and another one for their values, and associate them to my entity by means of a foreign key?
What should I do in my JSP/JS Layer to dynamically paint a screen with whatever custom fields that are defined?
How do I let Spring MVC and Hibernate handle all this data model and the views?

I'm extremely sorry if my question is not framed or worded properly. I'm relatively new to these technologies, and would like to learn with each challenge.

Thanks,
Sriram

Best Answer

From the backend side, if you can give up some of the requirements there is a simple solution using JSON column in your table to store dynamic fields. In this case, you would have a map in your Project entity, and using Hibernate Types you can map them to JSON data automatically.

This solution is enough to store, retrieve and filter by dynamic fields and most of the DBMS engines now support JSON/document columns.

However, if the other requirements are mandatory you need to implement your own solution.

You can extend the JSON column approach by adding two entities: Field and Template. The Field represents fields names, types, and constraints whereas the Template represents customer project types. The relation between Project and Template is many-to-one since each template can have many project records. The template should be used from the application side to validate user inputs based on the template. After that, the data will be stored as JSON data in the same Project Table.

If the above solution is not enough you can depend more on the Database and let each template data be stored on a new table that has the template name. However, this solution is DMBS specific since (to my knowledge) Hibernate doesn't support creating tables at runtime.

Related Solutions

Service Layer vs DAO in Java – Why Both Are Needed

Generally the DAO is as light as possible and exists solely to provide a connection to the DB, sometimes abstracted so different DB backends can be used.

The service layer is there to provide logic to operate on the data sent to and from the DAO and the client. Very often these 2 pieces will be bundled together into the same module, and occasionally into the same code, but you'll still see them as distinct logical entities.

Another reason is security - If you provide a service layer that has no relation to the DB, then is it more difficult to gain access to the DB from the client except through the service. If the DB cannot be accessed directly from the client (and there is no trivial DAO module acting as the service) then all an attacker who has taken over the client can do is attempt to hack the service layer as well before he gets all but the most sanitised access to your data.

Java – Programmatically extending Hibernate table/entity definitions in Spring, how

As far as I can tell, what you are describing can be trivially implemented with an Embeddable class and not need of AOP.

@Embeddable
class Audit {
  Timestamp created;
  String createdBy;
  String updatedBy;
}

Then you can simply add your embeddable object within your entities.

@Entity
class Order {
   @Embedded
   Audit audit;
}

Using inheritance, you might just as well make this available for a set of entities:

@MappedSuperClass
class MotherOfAllEntities {
   @Embedded
   Audit audit;
}

@Entity
class ChildClass extends MotherOfAllEntities {
}

If the information being added is just audit information, as you seem to suggest in your post you may consider using something like Hibernate Envers which seems to be an implementation of what you're apparently suggesting with your question

@Entity
@Audited
class Order {
}

And Envers will make sure to store audit information about the entity in some other data structure.

Since Envers seem to be an implementation of something like what you want to do from scratch, you might just as well give it a look to their code and see how they did it, but yet again, if it is to implement what you described, to me it sounds like killing a fly with a bazooka.

Best Answer

Related Solutions

Service Layer vs DAO in Java – Why Both Are Needed

Java – Programmatically extending Hibernate table/entity definitions in Spring, how

Related Topic