Shulou(Shulou.com)06/02 Report--

This article is about how to use Hibernate/JPA. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

1) make friends with the database administrator

There is a trend that some Java developers ignore the importance of database administrators. This makes a big mistake, and it is essential to maintain a good working relationship with database administrators in order to achieve the success of any ORM (object Relational Mapping) technology. There are two reasons:

Individual database administrators cannot make Hibernate projects successful, but they can usually make them fail.

The database administrator has a good insight into the database itself and has good professional habits to tell you some mistakes and operational suggestions. I can remember many examples where the advice of a database administrator saves us a lot of time and provides us with a good solution.

In most cases, having good database administrators and maintaining a good relationship with them is critical to your ORM (object-relational mapping) work.

2) use a good naming standard (* mandatory) from the very beginning

We know that the discussion of naming standards will be controversial, but we must make it clear that our naming should make our data model meaningful, which makes it easy for developers to use so that they don't get confused. Therefore, how to name entities and attributes is very important. I have naming standards that I like and think they are *, but I don't want to impose them on you here. The most important thing is that you decide what naming standard to use and let everyone use it. In fact, not only naming standards need to be unified, but others are also needed (for example, Boolean types are denoted by "Yhand N" or "0 hand 1").

3) Don't try to map all the attributes

We always try to use tools such as Dali to map everything and form a table (some tables have hundreds of columns! ). This will be troublesome in the end. Why? Because we use a common, previous database, there are a lot of fields that we don't care about and never use. Mapping them can only cause performance problems and confusion.

4) Let the database do what it is good at.

We want to have a good, clear data model, so we write some additional queries to get object-related data at any cost, either using stored procedures or functions. This is wrong, and the advantage of the database is to store, rather than maintain, the data created or read and written by Hibernate. For example, we have an object with a state associated with it. This state is used throughout the application, so there is no doubt that it will be executed, but we don't want to write a separate query each time. The problem is that this state is derived from some statistical calculations, and these statistical calculations require an one-to-many relationship. The cost of reading data from loaded objects each time is very high. Later, I talked to one of our database administrators and found that a sql function we could use could quickly get this state. We use @ Formula to map to a state attribute and get everything we need. This is still part of the domain model, but it performs very well. Sometimes a compromise like this can make a big difference.

5) decompose the database

From the beginning, I wanted to model the entire database in Hibernate. It turns out that this is impractical for the following reasons:

A) it's a huge project, and it takes weeks, and users can't see what you're actually doing.

B) I can't fix it in * times, and subsequent developers will modify them anyway.

There is a tendency to map everything before you start, but when you start doing it, you don't have to spend a lot of time on it. I later found a good way to break down the database and work on it piece by piece, and found it very helpful.

6) pay close attention to triggers

There are two reasons to pay close attention to database triggers:

A) the trigger covertly performs some functions in the background, which makes you confused and don't know what's going on.

B) when you need to copy something on the hibernate side, the trigger will do something. We didn't realize this lesson several times before, resulting in the loss of a lot of data, which was caused by triggers, which almost made us depressed.

7) avoid using tools to automatically generate your model

Yes, the use of these tools can save time (although we found that Dali has a serious bug, but we still use it), but * you have to do a lot of things again. In fact, manual does not take you a lot of time, when you do it yourself, it will give you a chance to familiarize yourself with the data.

8) use named query statements (NamedQueries) as much as possible

Although it's easy to write queries, in many cases it's better to use NamedQueries, which will help you do two things:

A) it can be more reused because named queries are usually in important places in the code.

B) your query statement is correct at the beginning, so it is easier to find errors in the query statement.

It takes some time to get used to it, but it's worth it.

9) expected management

For any framework, technology, or even concept, this is very important and should be kept in mind. For some reason, people tend to focus on a feature that may not actually exist or may be exaggerated. Sometimes it's small and easy to understand (for example, to understand some actual work that needs to be mapped in Hibernate), and sometimes I don't know how they manage to implement concepts (such as how Hibernate manages plan fixes). In any case, it is important to find out what the expected goals are and then manage them. If your team thinks that Hibernate will make database administrators useless and fire them, then you will have a potential problem.

10) use the rich domain model (rich domain modeling)

One of the sad things that happens to me is that I use Hibernate when a domain object is just a simple data container, and tools like Hibernate let us use data in an object-oriented way. Simply mapping data just keeps us halfway. When I instinctively thought of using the rich domain model (rich domain modeling), I found that we could reuse a lot of code, our other layers became less cluttered, and our code was easier to test.

Thank you for reading! This is the end of the article on "how to use Hibernate/JPA". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.