There is a SiteAlarmRecord entity class, corresponding to the SiteAlarmRecord table, and its information should be displayed in the frontend.
This entity class has an attribute called alarm type (alarmType)
The data stored in the table is code, but the front desk needs to display the name corresponding to the code
code name These enumeration values are stored in a dictionary table
For example
code name
1 High limit alarm
2 Low limit alarm
In a situation like this, my previous approach was:
Give the entity class a redundant attribute alarmTypeCHN, which represents the Chinese name corresponding to alarmType.
But our project leader said that my approach was not conducive to later maintenance. He said that entity classes should correspond to table fields one-to-one;
He suggested that I make a vo class, let vo inherit this entity class, and then add these redundant attributes to this vo class.
I think this approach is also very troublesome.
What do you think?
给我你的怀抱2017-05-16 13:40:16
1. The front-end can get all the warning types when loading the page, so you don’t have to worry about it, and it’s not that troublesome to process it on the front-end
2. If the front end cannot get it, then add a temporary field codeName such as @Transient to the entity, and then query it jointly when fetching the data... I did this two years ago...