ssh架构，sevice层继承dao层 这种结构合理吗？

Question

架构

Answer 1

为什么？ 直接继承，例如userdao 继承 basedao，就不需要写add  modify delete 方法，直接调用方法就可以。

Answer 2

service与dao不应当是继承关系， 而是依赖组合关系。 本来三层架构就是为了解耦，将控制层、业务逻辑层、数据持久层分开，  你这样正好违反了这个规则。  虽然你通过继承将公共方法提取到baseDao中了， 但实际上他还是service的代码。java只能单继承， 你继承了baseDao将无法继承其它的类， 以后维护扩展都不好。

Answer 3

LZ应该认识一下spring IOC和AOP的作用，既然你选择了使用别人的框架，你却不用别人的功能，那你还使用别人的框架干嘛

Answer 4

总体上不合理，先把spring扔掉再说吧。那玩意要命的。

Answer 5

bean（实体类） -  dao（定义接口） -  daoimpl（实现接口） -  service（定义跟dao接口一样的接口）  -  serviceimpl（调用dao接口） -  action（引用service接口） -  xml  -  jsp
希望能帮到你。

Answer 6

service与dao不应当是继承关系， 而是依赖组合关系。 本来三层架构就是为了解耦，将控制层、业务逻辑层、数据持久层分开，  你这样正好违反了这个规则。  虽然你通过继承将公共方法提取到baseDao中了， 但实际上他还是service的代码。java只能单继承， 你继承了baseDao将无法继承其它的类， 以后维护扩展都不好。谢谢，做数据库开发好像还没有出现扩展不好的情况，userdao 继承 basedao的关系，逻辑上是继承的关系，也是组合的关系。一般做数据库开发service好像只需要继承basedao,还需要继承其它什么类？？？因为service层只有数据库的操作，新增业务逻辑，在service中直接添加方法就可以了，组合的关系不得不使service层重写basedao的方法，并且调用basedao的方法。我不理解的地方就是这种结构会不会出现异常或者并发操作中引起的问题