这星期在整理工程的文档。发现一些问题。
1、DAO层应该进行具体的操作还是抽象程度高的操作？
抽象程度越高，复用的可能性就越大。但是效率上确实眼睁睁看着它提高不了。
2、DAO层的操作应该事先准备完整的“增删改查”，还是等用到的时候再针对性的增加？
由于当初在开始建立工程时，时间紧迫而且需求不清晰，所以DAO层给所有的数据库表甚至所有表的字段都编写了“增删改查”的接口。这次整理代码的时候发现有好多数据表中的操作（如修改），或者某些字段的操作都是用不到的，因为业务本身就注定了这些字段一旦写入就不会再更改或不允许更改。所以，本人其实更倾向于后者，即用到的方法在添加。一是代码结构更清晰也更有针对性，二是不必浪费程序员的时间开发不用的代码。毕竟不是搭建开发平台，要提供尽量充足的接口。更多情况下，都是有针对性，面向一定需求来进行开发的工程。
3、当原先定好的类需要增加新的属性时，是增加到类中还是新建一个类？
在工程中也遇到这个问题。原先工程是没有经纬度这个概念的，在后期的完善中为了使用百度地图而增加了经纬度。为了不破坏原先的数据库表，新增的经纬度信息新开了一张表进行存储，相应的也就多了一个DAO类为其进行数据读取操作。但是在MODEL层中就遇上了尴尬的问题。新建一个景点时，可以传入两个参数，一个是原先景点的基本信息，再一个是经纬度信息。但是在获取景点时就遇到了麻烦，因为java中函数只能有一个返回值，所以如果在编辑景点时需要同时展现景点的基本信息且展现经纬度信息的话，就需要调用两个函数来完成，但是其实逻辑上应该只需要一个。
现在的现状是经纬度信息封装成一个Bean，那么在不破坏现有代码结构的基础上，可以在原来的SightBean中增加一个经纬度Bean属性，这样就可以解决事物增加了属性而函数却无法返回新属性的问题了。相反的，如果将经纬度信息不进行封装，而直接增加到原来的SightBean中，那么与经纬度相关的DAO层的传递数据类型都要由经纬度Bean更新成景点Bean，数据冗余不说，更改代码后的测试问题就是牵一发而动全身。
4、业务逻辑变复杂时，复杂度是否应该向下转移？
servlet本身应该是作为页面请求以及业务层处理之间的接头人。但是在之前的开发中，servlet承担了过重的角色，一部分逻辑判断放在了控制层。其实逻辑判断放在控制层也不能说是错的，因为控制可以想象成多闸开关，控制它接通哪一个，判断也可以算是其中一项任务。但是现在一部分的业务逻辑已经流到了控制层就是很可怕的事情。业务逻辑应该严格的控制在业务层中，只有这样才能将展现与模型分离，当换一种展现方式（如从web方式转为桌面方式时）才可以不改动模型而只变更展示层的代码。
另外，如果业务层的复杂度增加，如需要多个跨表操作时，这个复杂度是否应该由模型层下移到DAO层，由sql语句来完成？如果下移，那么应该下移到哪个DAO？
DAO层中的类应该与每一张数据表对应还是应该与业务模型中的事物的类型相对应？现在的做法是与数据表相对应，为的是数据接口层与模型层分离。这样当业务模型改变时，数据接口依然可以保留以适应新的业务模型。但是这种选择导致的跨表操作的尴尬问题又让选择那个DAO进行跨表SQL变成了一种权衡。