Hibernateutils and third-party Boundary

It took an afternoon to reconstruct the code at the database interaction layer, reducing the piles of code. How many grams should it be called? I also thought of a template method mode, which further reduced a lot of getsession and closesession. It feels pretty good. If you have missed out or are not doing well, please kindly advise.

Package COM. CCNU. salary. utils; import Java. util. arraylist; import Java. util. list; import Org. hibernate. query; import Org. hibernate. session; import Org. hibernate. sessionfactory; import Org. hibernate. cfg. configuration;/*** reusable code for database interaction **/public class hibernateutils {Private Static sessionfactory factory; private hibernateutils () {} static {configuration CFG = new configuration (). configure (); factory = C FG. buildsessionfactory ();} public static sessionfactory getsessionfactory () {return factory;} public static session getsession () {return factory. opensession ();} public static void closesession (session) {If (session! = NULL) {If (Session. isopen () {session. close () ;}} public interface actioninsession {object dosomething (session);} public static object templatedexec (actioninsession AIS) {session = NULL; try {session = getsession (); Session. begintransaction (); object OBJ = AIS. dosomething (session); Session. gettransaction (). commit (); Return OBJ;} catch (exception e) {e. printstacktrace (); Session. gettransaction (). rollback ();} finally {hibernateutils. closesession (session);} return NULL;} public static void save (final object OBJ) {templatedexec (New actioninsession () {@ overridepublic object dosomething (session) {session. save (OBJ); return NULL ;}});} public static void deletebyid (final class C, final long ID) {templatedexec (New actioninsession () {@ overridepublic object dosomething (session) {object OBJ = session. load (C, ID); Session. delete (OBJ); return NULL ;}});} public static void Delete (final object OBJ) {templatedexec (New actioninsession () {@ overridepublic object dosomething (session) {session. delete (OBJ); return NULL ;}}) ;}public static object findbyid (final class C, final long ID) {return templatedexec (New actioninsession () {@ overridepublic object dosomething (session) {return session. get (C, ID) ;}}) ;}public static object findbycondition (final string hql, final string param1, final string param2) {return templatedexec (New actioninsession () {@ overridepublic object dosomething (session) {return session. createquery (hql ). setparameter (0, param1 ). setparameter (1, param2 ). uniqueresult () ;}});} public static list findall (final string hql) {return (list) templatedexec (New actioninsession () {@ overridepublic object dosomething (session) {return session. createquery (hql ). list ();}});}}

When introducing third-party frameworks or code, we should exercise caution in controlling the scope and impact of the Code, rather than simply using the convenience it brings with no scruples. In other words, to limit third-party code to a single scope, the third-party boundary is called the third-party boundary when the framework needs to be used for replacement and will not affect the system as a whole. Hibernateutils is such a third-party boundary. It limits the impact scope of the Hibernate framework to a class. You only need to change a few items when you need to modify it. Of course, this is mainly a demonstration. In large projects, more precise measures may be required to achieve truly stable and reliable third-party boundaries.

Note: In fact, spring hibernatetemplate has already done this job, and is more reliable than this article. It is helpful to know more about some open source components and libraries to avoid repeated work. Of course, the biggest advantage of using self-compiled components is simplicity and flexibility. You don't have to borrow a car for a tire.