The second half of August, on the basis of the first half, according to the new needs of customers modify the original approval subsystems perfect reconstruction, to meet new needs. The following analysis of the work summarize the contents one by one.
1. The first job is to take business data and state data separate approval process. There are two reasons, first, this design will be more clear, the future is also easy to maintain. Second, query objects to support multiple customer requirements. (Before a query is an object, in fact, it is the manager made a mistake here, demand has been checked more). Then the question came before is a table now is to be divided into a lookup table (stored query public information), the object table (stored query object information) and process information table (storing the current state of the approval process node), because previously, only one table, the corresponding data access model only called totalModel. Then because of their lack of experience, the service layer also share this totalModel, because then deposit into three tables corresponding model should also be increased to three. So the question becomes, this original service layer also depends on the totoalModel, so if we want to break it into three model if you want to modify where an exceptionally large number. Here mainly to previously written code do not have to modify, and have to complete follow-up with the development of three new model. Here I would like is a combination of the three model into totalModel inside, and then do the appropriate package for the getter setter totalModel. Local code prior to such use will not have to modify the properties totalModel, only part of the required properties of the class to the set value of the combination of the class and then provided to the class object composition in totalModel.
2. then uses this model, I was in the service layer and the layer data dao public the same model. The benefits of this are easy to use, do not build many of the concepts duplicate model. It had significant drawbacks, service layer dao layer and coupled together, not easy to maintain. Did not separate the two layers of the model is that the model needs two are the same thing, there is no need to separate. Well, now it seems it is necessary to separate the reason is that we can address the impact of a first point summary table structure occurring under the premise dao data access layer interface unchanged, the impact on the service layer is to be isolated, and vice versa versa. The second point is, Model data access layer tend to be more comprehensive, as it will contain all the fields in the table, but the model service layer may be only a relatively small subset, or according to the service extracted from several abstract class. So taking into account these two points, the common model is better or not.
The above two points are the lessons from the work of it.
The following is tucao ---------------------------- (supplemented on time) ----------- ----------------------