from jdbc to hibernate, from hibernate to mybatis, has been numb to follow the trend, using
for work use.I now have an idea to encapsulate and develop using jdbc+redis on the basis of JDBC, so that I can ravage jdbc in my own way
I wonder if it is feasible and problematic to carry out long-term development in this way in a formal environment.
do large companies encapsulate their own persistence frameworks or use off-the-shelf persistence frameworks?
there is no problem with self-encapsulation, just whether there are enough resources and time to do it.
the main functional points of the existing persistence framework are multi-SQL dialect support, multi-data source configuration, data table mapping (and linkage processing of entity field changes and database table field changes), caching and automation tool support.
if the business only needs to support a specific SQL dialect, a small number or even only one data source, the linkage requirement of data table mapping is not high, and the cache is not very needed, then self-encapsulation is not a bad choice. As for automation tool support, IDE usually comes with some, followed by SQL splicing tools and the like, as long as you are familiar with the syntax of design patterns and target SQL dialects, it's good to do it yourself.
Special , about data table mapping linkage, take a chestnut:
from a personal point of view, it is good to accumulate experience by messing around with the wheel, but you have to be very careful if you want to go to the production environment. Because this is a basic tool, in addition to having a strong basic ability and understanding of jdbc, it takes a long time to polish and stand the test of various production conditions in order to be available in the production environment. Now all kinds of mature frameworks have to be upgraded by various companies to achieve such stability, and it may take longer to expose the hidden problems in their own frameworks, but if something goes wrong, it may be in large quantities, resulting in data loss and duplication.
evaluate so many frameworks if they don't meet the requirements and do understand that the difficulties of implementing a new framework are bearable, then do it.