Home >Backend Development >PHP Tutorial >PHP+Java development experience: Don't be too object-oriented_PHP tutorial
PHP+Java development experience: Don't be too object-oriented_PHP tutorial
- WBOYOriginal
- 2016-07-15 13:26:27842browse
Speaking of object-oriented, many languages now have some. Java is a traditional object-oriented language, and PHP is also somewhat object-oriented, but not very good. In a specific project (this article is a Web development project), being completely object-oriented is sometimes not the best choice. The author of this article finally chose a model of PHP+Java and shared some of his own experiences.
I came into contact with C++ (high school) earlier and accepted object-oriented thinking earlier. Object-oriented thinking is closer to the way people think, and its features such as encapsulation and inheritance can often simplify some work. The most important thing is that the ideas look much clearer. I firmly believe in object-oriented thinking, until one day, I got confused in the WEB project.
My previous work was also related to WEB development. Usually the projects were interfaces, implementations, service layers, and DAO layers. Over time, I got used to this pattern. Later, I started to make my own website (operate it myself), and I also followed this model. It took me a while to get the thing out and it could run, and problems arose. As we all know, things like portals, especially websites in the growth stage, may often face some changes and expansions. It is not like an enterprise project or a website operating in a stable mode, where a set of written programs can be used continuously. But JAVA things are a bit troublesome to change.
First: A lot of interfaces are used in the project, and interfaces often need to be touched during business changes. Some people may say that this is because the demand is not met. Yes, you can think so, but there is a premise: the demand cannot be met in one step, otherwise the website will not run. When the demand analysis is completed, the flowers will wither. Recall this classic process: to add a feature (the page part will not be discussed for now), first add or modify a service interface; then add or modify its implementation; then if necessary, you may also add or modify a DAO layer interface, corresponding to We need to add or modify its implementation; in the end, what we really want to change is often just a SQL statement.
This series of processes is too cumbersome. The portal website basically displays information, and its business logic is basically reflected in SQL statements. Think about it, what is displayed on the website, how to sort it, how to aggregate it, don’t these all correspond to the corresponding SQL statements? If you have to write the DAO layer as basic additions, deletions and modifications, and then make a fuss in the service layer to implement the business logic that originally corresponds to a SQL statement, what's the point? Layering purely for the sake of layering? Object-oriented for the sake of object-oriented? Not to mention the pile of interfaces, which will increase the workload in vain. Of course I will not deny the significance of interfaces in programming thinking, but are the bunch of interfaces in traditional JAVA WEB programming really a reasonable application? I think in many cases it's not. I later used PHP to rewrite a large part of the functions in my project, which took only a few days, without layering or interfaces. The improvement in work efficiency brought about by this is really pleasant!
Second: The release of JAVA WEB projects usually requires restarting the service, causing WEB operation interruption. Many people are discussing hot deployment. I don’t know what level Hot Deployment will eventually reach, but I don’t think it will be able to modify files at any time and take effect at any time like PHP. In order not to interrupt the service, I usually choose to form a cluster and release in turn. Although this may still cause some problems, it is much better than interrupting the application. However, clustering will bring trouble in publishing, and the cluster itself may not be what I really need.
There are also some minor problems that come with it. For example, if my project contains some folders that store a large number of files, I have to deal with them specially when publishing, which is very uncomfortable. Even if you make a soft link, you will inevitably have to do extra work when publishing. Of course, I believe there are better solutions to these problems, and I personally am still exploring them.
Faced with the above problems, I finally stopped sticking to object-oriented. I changed the project to a pre-PHP and post-JAVA format. PHP seems to be much more flexible as a front-end. The entire revision did not take much time on the logic part of PHP, and all the time was spent on page design; the JAVA back-end can ensure stability and efficiency, and is easy to design safely. From this, I finally uttered the exclamation "Don't be too face-to-face". Demand determines everything. Following other people's thoughts is no different from joining a cult.
The problem is not over yet. For the JAVA back-end part, I am still exploring a plug-in-based CMS back-end system that can hot load and remove plug-ins. Oh, you can’t beat the person to death with a stick because of the above reasons.
But no matter what, after reading the author's description, you might as well try the combination of PHP+Java: let's see what benefits can be brought by giving up some object-oriented.