Java处理业务逻辑的两种方式.docVIP

处理业务的两种方式(面向对象和脚本)，你选择哪一个？ 我觉得这两种方式的比较，就和面向过程和面向对象比较一样，没有谁好谁坏，具体问题要具体分析，针对业务进行抉择，本身做开发就是以业务为驱动！ 客观因素： 取决于项目组的java技术水平 或者是存储过程，sql的水平 因为，如果说一个项目组中，就只有一个人会存储过程，而且就只有他一个人存储过程水平高，那可能就必须统一用java oo的方式了，就不能用过程实现业务，毕竟这块业务，他写的过程代码只有他能够看懂和维护 ；反之。 取决于项目组的项目领导的规定： 有些项目经理他个人因素，讨厌和反对存储过程的方式的话，禁止用存储过程那就没办法； 反之 也取决于公司这些外在因素： 比如 “神州数码” 这家公司，他们的框架就是公司自己开发的，并没有用开源框架，他们对开发者的存储过程和sql的水平要求就很高， 因为他们自己开发的框架，大部分底层都是封装了的，很多都是用存储过程和sql去实现业务逻辑； 像在移动这边做项目，大家都是外包过来的，来自于不同的公司，做个开发简直就是没有限制，自由发挥，各人擅长的东西都给整出来了，呵呵，这个也是有坏处和好处的。所以做外包我喜欢看别人写的代码，这次项目中，我就看到了一个同事，整个项目组就只有他用存储过程来处理业务逻辑，因为他就是从“神州数码”过来的，呵呵。 具体比较： 存储过程对数据库的方言依赖重，一旦开发的系统，如果是用oracle要迁移到DB2时，那以前的oracle的存储过程就不适用了。 如果数据库确定好了，像银行一般用oracle的话，对性能要求高的话，存储过程要有优势一些， 其实我们写java代码的时候，就是将存储过程一一映射成一段一段的java程序来实现业务逻辑的， （所以我写到这里感觉有点启发，当如果我对一些业务逻辑确实很复杂的业务，假如因为某种原因必须要求java oo来实现的话，而自己又没有思路的话，完全可以先用存储过程来写好，理清思路，再将其转换为java oo实现。无外乎是一个方法，所以我也认识到oracle存储过程真的不能把它给丢弃了，虽然工作中没有怎么用到存储过程） 在对系统进行维护的时候： 如果是java oo的程序，修改代码后需要重新编译和部署； 而存储过程呢.，就是业务逻辑复杂了的话，估计只有自己写的人才看得懂，维护起来有限制； 用存储过程可以防止sql注入等一些安全性的问题。用存储过程也可以解决性能问题 总结 ： 业务逻辑实现方式：（最重要的是应该要清楚什么业务什么情况用什么去实现） 具体要选择哪种方式的话，没有可比性，只有具体问题具体分析，只有在项目中不断的总结和认知，找出共性和处理业务逻辑的方法： 比如，找出类似于某种业务------则采用存储过程； 遇到某种业务-----------则采用程序实现 归根结底就是总结：根据某种业务需求来确定使用和找出最方便和最好的方式来解决和实现业务逻辑