It is also the experience summed up by previous projects integrating preferential activities.
Question :
In traditional web services, addition, deletion, modification, and query are implemented through the database. The javabeans in the model layer generally correspond one-to-one with a table in the database. But in this project, I cannot filter the data I want by querying the database.
For example, for a preferential activity, he has N types of restrictions, such as the name of the hotel, the day of the week for the check-in date, which bank organization the credit card is swiped, the level of the user, and so on.
Well, it's not too much of a hassle to look at it this way. When the project is halfway through, it is found that the demand has changed. There are multiple income items for a preferential activity, such as points, discounts, valet parking, and movie tickets. The restrictions on each income may not be the same.
So I sat on the wax.
Solution :
The poor will change, and the change will pass. When I decided not to use database queries, the whole world opened up.
Because the amount of data is not large, only a few hundred, so I think the first version uses code to query directly (you can consider search engines later)
Design class diagram (introduction version):
Here, activity information and income restriction information can be stored in separate tables. When activities are generated, data is extracted from the database to generate restriction types (with internal judgment rules)
Conclusion :
Similar to the Dependency Inversion Principle. The design of Java classes should take precedence over the design of database tables. The database only provides services for the system, and should not be an obstacle that restricts the design of the system.
This experience has not improved my technology, but it has given me a wake-up call in analyzing and solving problems. I used to be too accustomed to traditional web back-end development and rely too much on tools mentally.