Database: Let's talk about easydbo's persistence strategy.

Let me talk about some of my personal views on easydbo. easydbo is a lightweight and only supports single tables currently.
The persistence framework of ing, Which is ultra-lightweight, means that it is very simple to start with and easy to use, but note that it is a single table ing, which leads to some special processing when dealing with some mappings. Here I am talking about some individuals
Easydbo is used for general persistence strategies.

 One-to-one

The one-to-one relationship can be divided into two situations: first, the primary table's ing from the table
. For example, name (firstname, lastname, midnmae) tables and user tables, because easydbo only supports single-Table ing, if the table granularity is too high
Fine, will lead to the generation of extremely fine domain objects, such as the generation of name objects, and the need to create crud methods for these fine-grained objects, and easydbo is not as similar to hibernate
And if you do not use the Easyjf-dbo.xml to configure (that is, directly use the class to implement the iobject Interface), you cannot even
The private member declaration of the name object appears. In this case, it is best to combine the name table with the user table. The second is the ing between large tables and large tables. In this case, only foreign key associations are used.
. But also pay attention to easydbo is not yet a perfect persistence framework, I think it is very important to leave the easyjf-dbo.xml configuration to persist the object, if
Directly use implements iobject (which is the most convenient and simple way for me to use. I must have used hibernate to use easydbo.
You cannot use oo completely, that is, private bbsdir cannot appear in bbsdoc; instead, you can only use
Private string bbsdir_id.

One-to-multiple

Through the above analysis
In this case, it is best to use a foreign key Association (multiple parties actively associate one party ). Therefore, xxxset and the like cannot appear in one of the domain categories (except for configuration files ).
In this way, one-way Association is implemented. To use bidirectional Association, you can only add one util class to one party and use the query method to obtain the list of multiple parties.

Many-to-many

 
The case of many-to-many is complicated. Generally, an intermediate table is created to manage the relationship between the two objects. In easydbo, there are two cases. For example, user and
Role, which is a typical multi-to-many ing relationship, is common in the user permission management model. So how to deal with this many-to-many problem? First, create a user-
Role table, which is required. In the second case, the user-role table is directly used. In this case, the user-role table is not processed.
Userutil creates a list getroles () method. In this method, SQL statements are directly used to perform a two-layer nested query. This method is good.
JDBC programmers are familiar with it, but it is troublesome and frequently used. The other is to create a userrole object for the user-role table, which is recommended by me. Create
The object does not mean that it is simply a bridge object (I myself call it an object created for a table that only plays an excessive role in the middle ), I thought I could not make good use of this object according to the actual situation.
For example, in the user permission management interface, we will list all permissions of a user or list all users in a permission group that belong to only classes, then we can go to the user-role table (that is
Add redundant fields, such as username and rolenmae, to facilitate page merging.
Use # foreach ($ userrole in $ userrolelist )... $! Userrole. username and so on to simplify page editing
In this way, the number of queries to the database is much less, and it is troublesome to use the first one. However, you must note that you cannot add too many fields. After all, these are redundant data.