This text transferred from the Guty O-R Mapping J2EE is CMP Entity Bean, and the most illusory disease is also it in practical applications. We have been investigating the development method of CMP2.0 for half a year, and the current amount can be reduced to 70%, and it is hoped to reduce 90%. I have been very satisfied with existing results, but when I really read Hibernate, the confidence of CMP2.0 was completely shaken. Hibernate has the following advantages over CMP2.0: 1. Compatibility. The norm is exactly the same, and it is different, which is the status quo of CMP. Use third-party O-R mapping tools to solve this problem. 2. Protect intellectual investment. After understanding Orion, WebLogic, JBoss's CMP implementation, I don't want to learn WebSphere or resin. 3. Performance. a. Local VS Remote, Hibernate, JDO, CASTOR is local call, although there is also a local interface, but the web layer still needs to access the EJB layer data, serialization, network call, create a large number of objects through the Remote interface. It is why performance reduction. b. Transaction, J2EE puts forward a new transaction model (Method-based Descriptor), which is really a "simplified" development of programmers, remembering a tutorial recommended that all EJB methods are used with Required. But what is the result? Performance is extremely low! Interlock! There is no way, we only adjust the Transaction properties of each method, and then new interlocks ... new transaction model is unsuccessful. It tries to simplify the problem, but it introduces a more serious problem. The transaction implementation of each manufacturer is not the same, and some support Optimistic Lock, some in the VM synchronous Entity object, and a big enemy of compatibility. Hibernate did not try to create an updated mode. On the contrary, it took the transaction programming mode of the traditional database. After seeing it after the transaction of J2EE, it is very kind, I feel very kind, I feel that I am programs, not to fill the code . 4. Dynamic query. Entity Bean is difficult to implement dynamic query because it is based on code automatic generation technology, that is, the final execution code is generated during deployment compile. Hibernate has an fundamental change, it is based on the reflection mechanism, and the dynamic query is very natural. In addition, Hibernate supports all SQL syntax, which can be done by traditional databases. 5. Development speed. I have a DREAM, one day entity bean will become very good. But at least, Entity Bean is an imperfect product. It is a large company's political struggle and a compromise product, and habitually puts some questions "indefinite shelves", typical example is Query (not mention other issues) It is because others are the fattest injuries of Entity Bean :)) Form a strong contrast, Hibernate's core programmers have only one person, but it improves the speed of Entity Bean. 6. Inherit and polymorphism. The essence of OO language is in Entity Bean. I have a self-comfort to see the Entity Bean to make a "data sheet in memory", I found a little balance. But when I saw Hibernate, I was not balanced. In addition, some of CMP2.0 also have some disadvantages that can be compensated. 1. Code maintenance. A large number of interface documents and profiles, development and maintenance work are great.
Solution: Use XDoclet, you can automatically produce many interfaces and configuration files, even advanced modes such as Facade, Delegate. At least, Hibernate's shortcomings are: 1. The code maintenance Hibernate provides a tool that automatically generates the mapping file "Frame", but also needs to be handled manually. And this kind of development, the best mode that can be thought of is the mode of XDoclet (code comment). Fortunately, Hibernate's programmers have added Hibernate modules to the XDoclet project. It is now required to wait for the next release of xdoclet. Conclusion: Hibernate bends at least from the document, there are many Entity Beans, I want to learn Hibernate. The following is the point of Robbin. If you don't use the Session Facade mode, I think EB is still a very meaningful thing, because EB is the only persistence scheme that directly supports RMI. However, due to the efficiency of EB and reduces network calls across RMI, EB has been fully encapsulated into the back of SB, and the distributed call of EB, the security verification function of EB, EB's container transaction function is completely previous SB Due, the result is only the only ORM function left, and the ORM is really a very very bad thing. So what is the function of EB worth doing? Using Session Bean DAO Hibernate to replace Session Bean Entity Bean, not only reduce software design difficulty, software development difficulty, software debugging, and software deployment, but also improve allowable efficiency, reduce hardware requirements. Don't compare the EB directly and Hibernate. The two are not something in a category, but should compare both options: Session bean Dao Hibernate session bean entity bean I can't find the second program? Good than the first solution. CMP can use CMR to represent the relationship between the multi-tables. But you will still encounter the situation that even if there is no key association, it still needs to connect the query, this is a very common phenomenon. If you are hibernate, you can define Outer Join in HSQL. BMP can also write JDBC, and CMP does not have any way to solve this problem unless you define the needed connection queries as CMR, but if you want to connect the query, Or the key associated table must be played inside a package. If you don't play it in a jar package, if you can build a CMR? I don't want to put it in a jar, but I have to put it in a jar. Basically, CMP is still very awkward. Another big disadvantage of CMP is that it is not possible to dynamically SQL, and Guty has already been mentioned. A SQL is to define an EJBFinder method, and it is determined when compiling. In practical applications, you often encounter queries that are uncertain in query conditions. For example, users use the drop-down list to select the query on the page, and the user may not choose anything else, and some conditions may be selected. What do you do at this time? If you have n query conditions, you want to write C1N C2N C3n ... CNN (c is the compliance with the combination formula, n is the subscript, 1 ... n is the label) an EJBFinder method, very Horror. In fact, JDBC's PrepareStatement does not solve this problem very well because it is set in the order of 1, 2.
