• 博客园logo
  • 会员
  • 众包
  • 新闻
  • 博问
  • 闪存
  • 赞助商
  • HarmonyOS
  • Chat2DB
    • 搜索
      所有博客
    • 搜索
      当前博客
  • 写随笔 我的博客 短消息 简洁模式
    用户头像
    我的博客 我的园子 账号设置 会员中心 简洁模式 ... 退出登录
    注册 登录
编写人生
写写代码,写写人生
博客园    首页    新随笔    联系   管理    订阅  订阅
谈IResourceServiceProvider对IServiceProvider的改进
IServiceProvider是一种常见的对服务定位的描述。 他认为,在一个容器中,对于某种服务来说是唯一的,例如不可能存在两个剪贴板服务,而且这也屏蔽了对服务位置的关心。这种设计对于工具类软件十分有效,例如各种设计器软件,但对于具有庞大且重复性很强的数据库类软件来说,他是不太适合的。

IServiceProvider是一种常见的对服务定位的描述。

 


他认为,在一个容器中,对于某种服务来说是唯一的,例如不可能存在两个剪贴板服务,而且这也屏蔽了对服务位置的关心。这种设计对于工具类软件十分有效,例如各种设计器软件,但对于具有庞大且重复性很强的数据库类软件来说,他是不太适合的。

例如,订单模块中包含了Create、Read、Save和Delete方法,而客户模块同样包含了CRUD操作,最简单的办法是建立IDocumentService接口,包含了CRUD操作,但由于IServiceProvider无法为你区分你是申请订单的还是客户模块的,所以你必须从IDocumentService中派生出两个新的接口。

 


但是你要知道,现在的数据库软件动辄
1000多个模块,这个工作量非常巨大,而且他还有致命的弱点:你无法在运行时通过模块的名称得知对应的接口。例如你的网页中想来上这样一个链接:

/Ordersheet?action=delete&&oid=12345

所以IServiceProvider的问题总结是:

- 在容器中包含很多重复的服务,不过他们作用的资源不同,操作也可能不同,IServiceProvider无法提供这个特性;

- IServiceProvider还无法检索某个资源的特定接口的支持情况。

所以,IResourceServiceProvider诞生了。

 


新增的
resource参数帮助定位不同的资源,以便获取不同的实现。通过这样的设计,你将解决上面的问题。

posted on 2006-10-24 15:07  编写人生  阅读(1443)  评论(0)    收藏  举报
刷新页面返回顶部
博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3