根据近期接触的知识和问题整理，主要说明： 开发中我如何处理那些业务逻辑。。。
1。 架构
形容事物的整体构成，去除内在的修饰、实现内容，最后留下的构成事物的骨架就是架构。
e.g ： 庖丁解牛,他熟练在于熟知牛身体的骨架，知道从哪下刀，在哪应该注意等等。
再来看看项目工程，无论是刚开始做项目还是给项目做二次开发，我们最先就应该了解的是“架构” ，从客户手中的请求到服务器那端的响应，在此过程中经过这一系列的函数调用和数据操作，才完成一个功能点。 虽说觉得复杂，但也不复杂。 因为你长期和这类事物接触就觉得大同小异了。
也许对于我们来说：Struts2+Hibernate+Spring这一框架(也是架构)非常熟悉，成套的规则，易懂的操作，扩展性强，处理大数据也不马虎。 这就让我对它形成了依赖，久而久之按照非常老套的方式来编程：
POJO->业务逻辑->DAO
插曲：之前在学院内接触到的PHP小框架---每个请求都会进入index.php主程序，然后根据url的访问路径来将访问不同的模块，然后来执行各自的业务逻辑函数，最后CRUD数据并交互给前台页面显示。
而这衍生出来的JAVA小框架，思想近似相同，看上去好像会对每个POJO创建DAO、SERVICE、ACTION，可想而知那工程文件就相当庞大了，框架的思想很不错，但却让我发现我渐渐的依赖它，一直误解了模块如何去分块，我建了个TestAction，Test页面中的请求全扔给TestAction来处理，那往后是不是有了相同操作也都要如此操作呢？
靠着这些无脑操作，更让自己觉得很久没学到东西了(除了一些技术) ，日常做的无非就是对数据库的CRUD、页面业务逻辑更改、前台页面效果的处理。
说到底这些东西其实是我们都在做！ 那我们觉得自己已经能够熟用他们。并且设计完美了吗？ 我觉得没有！
2. 业务逻辑
我就觉得我没有掌握，在某些方面完全就是个小白！
----因为新项目在上线，着手开始构思，设计数据库，触发器对数据处理(省去很多逻辑代码)，分析功能需求，以每个POJO对象为单位来创建DAO、Service、Action，这样貌似一个整体的架构就基本完成了， 但是今天boss却跟我说“你这样的一个设计 以后编码你不觉得你很累吗？” 当时我就觉得 这样的做法很平常啊，也很容易让人一看就懂了！
问题： 从软件制作流程来看并没有什么错误，但是在业务逻辑处理这方面却发现 重复性的工作很多很多... (虽然一个POJO一个Action让人好找代码，而且结合页面的功能就能找到相应的逻辑函数，但是牵一发而动全身的道理我们都懂，这样的代码将不利于后续开发，现在又有哪个软件能做到一步到位，永久使用？----起码连个API也要不断完善和更新的，自己写的代码更是！)
3. 解决(架构+业务逻辑)
业务逻辑：
1. 设计逻辑层之前，按照如下流程：存在哪些对象、需要哪些操作(业务逻辑)、需要哪些list(与前台交互数据)
也就是处理业务逻辑层时, 如果项目小的话，就可以按：对象 来划分 ，至于一些共同的逻辑操作和需要的数据操作，我们可以用继承体系来解决，减少代码的编写量
2. 针对大项目，逻辑层易变动(就是前台页面数据需求更替)，我们就要为数据处理的业务逻辑单独处理，用最少的代码管理一类操作。
拿到一个项目对其进行二次开发，按照我现在的开发流程：
1. 发布访问、大致了解站内基本功能，划分了几大模块，有个印象就行
2. 了解 Http请求处理机制，以及数据交互的一整套流程
3. 熟知项目的整体架构，如：继承体系、站内配置、DAO数据访问、业务逻辑的划分，以及是否颠覆你的思想让你受益匪浅！
4. 完成上述流程之后，如果你能在了解全部的功能并整理文档划分好规则。后续的开发只需要根据自己拟定好的逻辑规则实现方法就好了，至于最后取数据也就小菜一碟