A recent project was implemented using the Java ssh framework. Using hibernate's own entity-to-database mapping framework, I also use the mapping class to encapsulate a conversion class from ResultSet to entity List (so that you can directly call your own function to convert SQL statements without the conversion of hibernate) Into the entity List, without writing cumbersome hibernate xml files).
However, everyone should know that the entity List method is strongly typed, and each table must have an entity corresponding to it, which is really tiring.
Personally, I feel that hibernate still does not have the weak type conversion of .net DataTable. It is too tiring to build an entity for each data table. Although the code generation tool can replace the generation, it has to deal with complex table association queries. , Or the table structure has been changed, and several files have to be modified each time, which is really annoying, and for some dynamic websites whose table structure is dynamically created by users, such mapping is not flexible. So I personally think that this type of framework is only suitable for simple applications, and it is really a bit more effective to change more complex applications.
Microsoft’s .net also has a similar data framework called LinQ To SQL, which is a hibernate-like entity-to-database mapping framework, but I want to say that the development efficiency of these database frameworks has actually been greatly exaggerated, yes, for Some simple applications, applications with few associations and few modification of table structure can be generated with a code generation tool. However, in the design stage of the project, it is impossible to design all the fields of the database so accurately, and the associated query may also be very complicated. After using these frameworks, future changes will be very painful. For a database change, several files must be modified, and even related entities must be modified.
In fact, what is the realization of the entity? In fact, the purpose is to transfer the service layer (such as the Action of the MVC framework) to the view layer. In fact, .net already has such a delivery feature. For example, in the .net MVC framework, ViewData["mytable"]=datatable can be used in the action, and Datatable datable=(Datable)ViewData["Message"] can be used on the view page to obtain code separation. The .net WebForm framework is even simpler and can be obtained directly by variable name or ViewState.
Of course, entities also have the benefits of entities. For example, after the view field is added to the action, the action can automatically assign values to the entity objects through setters instead of assigning values one by one. In fact, this is the only advantage of being an entity. In fact, this problem can be completely encapsulated by yourself through the Reflection class of .net or java. An automatic assignment class from form variables to action variables. If you build an entity simply because of the automatic assignment of view to action, I think it is worth thinking twice. Unless your system table association is very simple, the table changes are also very few. Otherwise, the weak type conversion of datatable should definitely be the first choice. In fact, Java developers can also write such a weakly typed datatable class, without having to create an entity for each project and each table. Through some encapsulated SQLHelper classes, the sql statement is directly converted into a weak type datatable. No matter how complicated the table association is, the generated weak type datatable is simple and straightforward.
In fact, in the development of the framework, I still think that the development model of Action+SQLHelper class+view or .net’s WebFrom Service backend+SQLHelper class+aspx is adopted to generate weak-type datatable through SQLHelper class. From code maintenance and development efficiency are the best choices.