javaee开发疑问，求大神
     本人小菜鸟一枚，入行半年不到。最近有一个疑问（如题）希望各路前辈指教下经验。
     我现在做的项目时比较传统的3层结构的项目。web层，service层，dao层
     第一，
     项目的页面功能上常常有很多条件并的查询，需要拼接sql或者更麻烦的还要写存储过程，现在这些都是在dao里面实现的。这样对么？我是说，感觉dao层做了很多事情，service根本没做什么。
     第二，
     在设计一个方法的时候，参数是null的情况。又分2种。
     1。方法的某个形参本身可以为null，
        也就是说业务上可能会有null的情况，这时候我是应该
        就写一个方法，让调用者可以传null呢？还是我应该再重写一个方法，将那个null参数隐藏起来？（看见前辈是把空参情况重写一个方法，这样做的好处？）
     2。方法本身不允许为null，
        那么我是否应该在方法里面先做一个非空检查，如果有空值，则抛出空指针异常，
        还是应该null时，方法自动使用空值参数。
        或者干脆不管，让他顺其自然？（这样有的时候也会抛出空指针异常，有的时候方法 却顺利执行了，但结果其实有问题……）
     第三，
     有很多返回List，Map作为结果的方法，当方法出错时，我应该返回null还是空   List，Map？

    先谢谢各路热心朋友了~
------解决方案--------------------
我来说下我的看法。
我参与项目不多。
之前做过的一个项目 Spring MVC+Hibernate。看到别人的代码，都是在Controller中拼接HQL的。真正的DAL其实是对HibernateTemplate等的封装。

其余一个用的iBatis，SQL自然是在xml中的。

个人觉得确实放在Controller中比较合适，拿到Form，根据条件拼SQL。只是觉得可以另外写个方法，让提供服务的方法去调用。方法体中的内容作适当拆分。形成一个个小函数（方法）。让你的Controller，调用这些小函数，完成业务功能。

至于第二个
第一点，参考你前辈的做法，既然可以传null，就重载一下，方便调用。你看看Spring，里面有很多类似的。
第二点，个人觉得业务上不为null的时候，你不要做检查了。因为你检查了也是抛出空指针异常。其他的还要看业务，如果（这样有的时候也会抛出空指针异常，有的时候方法 却顺利执行了，但结果其实有问题）这种情况，需要修改下你们的方法。

第三点。如果是公共的方法，调用者对结果遍历的话,建议返回List，Map 对象，里面元素个数可以是0个。当然调用者如果有get(0) 代码，还是要调用者自己判断。返回null和0个元素的对象实例其实没多大区别。总之还是要依情况而异。
------解决方案--------------------
第一个：service就是用于页面的逻辑跳转，业务逻辑放到dao中进行，service整合dao
第二个：基本将结果为null的作个封装，null放回一个""
第三个：看具体的业务逻辑了。出现错误了，最好返回List，map，但是里面只是没有元素而已。
------解决方案--------------------

引用:

引用我来说下我的看法。
我参与项目不多。
之前做过的一个项目 Spring MVC+Hibernate。看到别人的代码，都是在Controller中拼接HQL的。真正的DAL其实是对HibernateTemplate等的封装。

其余一个用的iBatis，SQL自然是在xml中的。

个人觉得确实放在Controller中比较合适，拿到Form，根据条件拼SQ……

我是这样使用理解和使用DAO和Service的，Service接口继承DAO的接口，Service实现类继承DAO的实现类，这样Service就具有DAO里面的方法了，而且不用Service单独管理事务了，而DAO里面的方法是很基础而参数比较抽象的方法，而涉及到复杂操作时，只需Service调用继承而来的基础方法进行封装成自身的方法。我感觉这样挺好的。