从pl/sql到J2EE的思考

以前是做oracle数据库的，通过使用pl/sql编写存储过程或者是业务逻辑代码的，现在转到J2EE开发来。

首先是语言上的变化从sql到java上，前者是脚本一系列的操作肯定没有java这种强类型重量级语言强大。不过两者聚焦的问题也不同，前者就是数据操作或者是一些简单的IO，后者通过包含JDK和第三方jar包具有强大的应用开发能力。

其次从应用开发的数据层变化到前台MVC全套结构的模式，相对来说后台数据操作还是比较单纯的，实现某些计算逻辑或者是数据操作。而应用的逻辑要考虑并发、性能、数据展现等等复杂的问题，相对来说说复杂一点。

然后谈谈两者工作的本质追求上的区别，在数据库端的pl/sql，这种管理相对混乱，逻辑独立简单的包、存储过程、函数、类型的结构中想要做好工作的核心是把握数据的获取、计算方法、数据输出的流程，要将其中的每个阶段都实现得必要的健壮和简单。毕竟这种代码的修改和变化的概率比较大，因此简单易懂，容易维护是最大的问题之一，如果是核心的程序，还需要必要的性能考虑，不过一般来说大多数的操作都是朴素的，不好听的话就是没有太多花招，技术技巧（简简单单的一点点行列转置，视图，临时表等技巧）。而J2EE中追求的是一种结构分明，一种高内聚低耦合的系统。如果一堆的类，一堆的jar，混乱的依赖关系和复杂的数据结构，以及恐怖的长不可及的方法，是毁掉代码的重磅炸弹。因此程序结构和应用开发框架，是重中之中。比较大多数的应用系统要解决的是显而易见的问题，也就是说存储大于计算的管理系统。如何将彼此模块之间的数据和功能进行划分和处理是一门大大的技术，需要不断的试验和重构。当前我也是菜鸟级别，总是绝对绝对好的架构，只有更好的业务抽象。面向业务进行编码，即使实现丑陋，都是可维护的。这是自己的简单的理解。

最后说说两者之间的发展吧，感觉前者已经是穷途末路了，面对No-sql和云计算等新型的数据处理方式，传统的关系型数据库系统程序，将会逐渐被替代，而且大多数重复的工作和维护都会进入自动化，乃至给运维级别的事情，和开发已经渐行渐远了。J2EE也是到了一个新的阶段，不断新的编码方式和旧有的面向对象的编码方式，进行巨大的冲击，解决多核、内存事务、高性能并发、分布式云计算上，将独立的业务对象进行抽象，然后用新的是实现编码方式才是真正要追求的，函数编程、脚本、Map-reduce 将不断发力，逐渐改变就有的JavaBean的格式，将J2EE大家族不断丰富。

随笔而写，其中有很多的错误，也是在所难免。