Today, I decided to change the data access scheme of JDBC STATELESS SESSIONBEAN to EntityBean. This means that my module is to be redesigned. This matter means that two lessons (all committed): 1. Don't think that you are more than others. When we designed this module, choose EntityBean, just think that EntityBean configuration and deployment too complicated, and EJB1.1 does not support Local Interface, resulting in the efficiency of complex data operations. And the Object-schema mapping is not much simpler than JDBC SSB. Who knows that it is found that once the relationship between complex points is to be handled, the code naturally complex. Finally, we have found that our design repeats many of the EntityBean, such as the cache of the item level (I wrote a Single-Write-Multiple-Write's cache module, waste time), configurable relationship map, and more Design pattern of stage agents. . . Those who have been carefully afterwards, the programmers of people are more than our cattle, and may not have to write manual data storage. Of course, there are a lot of problems, only invented the EntityBean solution, we are innocent than others Bowl B, completely forgetting Linus interpretation why the Linux kernel does not need C written in the Linux kernel: Being there, Done That. In fact, this lesson has been there. In the course of the previous document organization, I can write a common implementation method (Linked Bucket), I have to achieve the so-called supportable hashtable, the result is written for two days, and I still write badly . In fact, Eric is in his
The blog also mentioned that he had made a similar mistake, how can I go to my heart? 2. This comparison old set. It is the sharpener that is not mistaken. At the beginning of the project, countless books have said that there is a complex relationship of data access EntityBean is good, but I didn't think about why others didn't care, and I didn't have in-depth investigation. I forgot ancient training: Yu Yusheng, It is not allowed to waste.
