javaee开发疑问，求大神

Question

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

Answer 1

dao层是做数据访问的，service层是业务逻辑。web层是视图层
三者合一就是传统的M(model)V(view)C(control)层，它们各司其职，这种原则叫单一职能原则

Answer 2

第二个关于null的问题。。我们的项目中常用的一般是封装一下。比如toString。我们一般会给封装一下。比如叫个什么parsetoString之类的。内部实现就是：null返回""，非null就返回toString。第三个不一定吧看要求吧，有时候要求返回默认值比如“-”之类的

Answer 3

所有的一切看你实际需要  哈哈  很扯淡的回答  不过也没办法不过可以回答的是Service其实并不是什么也不做，简简单单的把所有的请求丢给dao(当然很多时候就是这样的)，但是当你需要同时进行多个操作，比如说你需要同时操作两个表，这时候你可能就需要调用两个dao，那么Service的好处就是可以综合起来处理这两个dao，从而是他们互不干扰

Answer 4

我来说下我的看法。
我参与项目不多。
之前做过的一个项目 Spring MVC+Hibernate。看到别人的代码，都是在Controller中拼接HQL的。真正的DAL其实是对HibernateTemplate等的封装。其余一个用的iBatis，SQL自然是在xml中的。个人觉得确实放在Controller中比较合适，拿到Form，根据条件拼SQL。只是觉得可以另外写个方法，让提供服务的方法去调用。方法体中的内容作适当拆分。形成一个个小函数（方法）。让你的Controller，调用这些小函数，完成业务功能。至于第二个
第一点，参考你前辈的做法，既然可以传null，就重载一下，方便调用。你看看Spring，里面有很多类似的。
第二点，个人觉得业务上不为null的时候，你不要做检查了。因为你检查了也是抛出空指针异常。其他的还要看业务，如果（这样有的时候也会抛出空指针异常，有的时候方法 却顺利执行了，但结果其实有问题）这种情况，需要修改下你们的方法。第三点。如果是公共的方法，调用者对结果遍历的话,建议返回List，Map 对象，里面元素个数可以是0个。当然调用者如果有get(0) 代码，还是要调用者自己判断。返回null和0个元素的对象实例其实没多大区别。总之还是要依情况而异。

Answer 5

   我现在的一个查询就是多表查询，但是，是在dao里完成拼接的。也就是说，数据其实是直接从页面开始传到了dao里，再做处理。照你的意思，这样是不对的？

Answer 6

 我可以这样理解么？也就是说Dao里封装的都是些类似于成型的工具的方法，不应该跟前面的业务逻辑有耦合（我可以直接把DAO层拿到其它项目中使用）

Answer 7

第一个：service就是用于页面的逻辑跳转，业务逻辑放到dao中进行，service整合dao
第二个：基本将结果为null的作个封装，null放回一个""
第三个：看具体的业务逻辑了。出现错误了，最好返回List，map，但是里面只是没有元素而已。

Answer 8

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