67,513
社区成员
发帖
与我相关
我的任务
分享MVC架构下各层接口的设计问题
首先，是Dao层接口的设计，究竟应该从业务的角度一个功能对应一个方法呢？还是单纯从数据库的角度做成增删改查的工具呢？这两种我都尝试过，哪种设计更合理我到现在仍摇摆不定。
或许文字描述不大清楚，就举个例子吧：
比如要做一个用户管理的功能，除了增删改查外，还有锁定/解锁、修改密码、部门调动……从业务的角度看这是几个不同的功能，每种功能对应一条sql语句。但是从数据的角度其实都是update单条数据的操作，只需要写成一个方法，Service层要修改哪个字段就传哪个字段就可以了。
第二，是关于Service层接口的设计，传入参数方面是统一使用实体对象传参合理些，还是采取语义化的传参合理些呢？这个问题我也是斟酌再三无法确定。
或许文字描述不太清楚，就举个例子吧：
还是以用户管理为例，如果采取实体对象传参，则无论修改密码、还是锁定/解锁，传参都是用户实体。而如果采取语义化的传参，那么修改密码的参数是(Integer id, String password)，锁定/解锁的参数是(Integer id, Boolean locked)。
附：希望大家从MVC层次职责的划分、使用起来的方便性、更好的应对需求变更、设计理念等方面考虑考虑这个问题。觉得“反正都能把功能实现，就可以交差了，管他那么多干嘛”的无所谓态度的就不用来搅局了。
或许文字描述不大清楚，就举个例子吧：
比如要做一个用户管理的功能，除了增删改查外，还有锁定/解锁、修改密码、部门调动……从业务的角度看这是几个不同的功能，每种功能对应一条sql语句。但是从数据的角度其实都是update单条数据的操作，只需要写成一个方法，Service层要修改哪个字段就传哪个字段就可以了。
第二，是关于Service层接口的设计，传入参数方面是统一使用实体对象传参合理些，还是采取语义化的传参合理些呢？这个问题我也是斟酌再三无法确定。
或许文字描述不太清楚，就举个例子吧：
还是以用户管理为例，如果采取实体对象传参，则无论修改密码、还是锁定/解锁，传参都是用户实体。而如果采取语义化的传参，那么修改密码的参数是(Integer id, String password)，锁定/解锁的参数是(Integer id, Boolean locked)。
附：希望大家从MVC层次职责的划分、使用起来的方便性、更好的应对需求变更、设计理念等方面考虑考虑这个问题。觉得“反正都能把功能实现，就可以交差了，管他那么多干嘛”的无所谓态度的就不用来搅局了。
...全文
请发表友善的回复…
发表回复
幻聪 2015-07-28
- 打赏
- 举报
从数据库的角度做成增删改查的工具dao接口 ...然后一个业务对应一个功能，分别实现调用dao接口现实各自业务
关于Service层接口的设计使用hibernate框架的话使用实体对象传参,而MyBaits就用采取语义化的传参合理
qqliang1314 2015-07-27
- 打赏
- 举报
看你数据库层有没有使用框架了，如果用hibetnate，那么数据库底层最好用公用的dao来封装增删改查方法，对于不同的业务方法，可以在service层写好处理语句，比如封装好对象，调用底层dao操作库。
迷林 2015-07-27
- 打赏
- 举报
不论怎么样变，都是针对数据库的增删查改，为了能够方便有效的管理代码，建议楼主各自用各自的接口和方法，充分达到降耦合的目的，从而方便的管理代码
董小姐_123 2015-07-27
- 打赏
- 举报
一个业务对应一个方法，分别实现各自业务的接口，这样不论是管理，操作都有一定的规范而不至于太多功能业务而糊涂！
ModMad 2015-07-27
- 打赏
- 举报
我觉得还是一个业务一个方法好
