Services层为什么要用(Services接口 类 + Services接口实现 类)分开,这样做有什么好处?

魔雨精灵 2011-06-01 07:22:57
使用Sturts + Spring + Hibernate框架开发, 通常采用MVC分层开发模式,Aciton处理请求,Services处理业务逻辑,Dao与数据库相关的操作。

例如工程的结构如下:
/*---------------------------------------------------------*/
Action:

HelloAction(请求处理,调用相应的Service,指定视图显示结果)

Services:

HelloService(接口)

HelloServiceImpl(接口的实现)

Dao:

HelloDao(数据库操作)

/*---------------------------------------------------------*/

Services层为什么要用(Services接口 类 + Services接口实现 类)分开,这样做有什么好处?(我想知道这么做的好处在哪里) 感觉Services接口类好像是多余的,而直接调用实现类,感觉代码更加简洁明了。
...全文
778 6 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
KG071 2011-06-01
  • 打赏
  • 举报
回复
可扩展 好维护
liyuntao609 2011-06-01
  • 打赏
  • 举报
回复
简单的讲 解耦
wl_ldy 2011-06-01
  • 打赏
  • 举报
回复
owen1201 2011-06-01
  • 打赏
  • 举报
回复
引入接口主要是为了服务分层,分层的话没层之间都用接口来连接
个人体会,代码不能写成大杂烩。 各个方法不能关联太紧,不方便维护,更不利于对接。多定义全局变量,硬代码少写。
magong 2011-06-01
  • 打赏
  • 举报
回复
这么做的好处有,
需要替换服务实现的时候比较方便。
典型如测试Web层的时候做一个Mock Service,把正常的服务实现替换下来。

另外,基于接口的设计在做动态代理和AOP的时候方便一点。

67,549

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧