IServiceProvider是一种常见的对服务定位的描述。
他认为，在一个容器中，对于某种服务来说是唯一的，例如不可能存在两个剪贴板服务，而且这也屏蔽了对服务位置的关心。这种设计对于工具类软件十分有效，例如各种设计器软件，但对于具有庞大且重复性很强的数据库类软件来说，他是不太适合的。
例如，订单模块中包含了Create、Read、Save和Delete方法，而客户模块同样包含了CRUD操作，最简单的办法是建立IDocumentService接口，包含了CRUD操作，但由于IServiceProvider无法为你区分你是申请订单的还是客户模块的，所以你必须从IDocumentService中派生出两个新的接口。
但是你要知道，现在的数据库软件动辄1000多个模块，这个工作量非常巨大，而且他还有致命的弱点：你无法在运行时通过模块的名称得知对应的接口。例如你的网页中想来上这样一个链接：
/Ordersheet?action=delete&&oid=12345
所以IServiceProvider的问题总结是：
－ 在容器中包含很多重复的服务，不过他们作用的资源不同，操作也可能不同，IServiceProvider无法提供这个特性；
－ IServiceProvider还无法检索某个资源的特定接口的支持情况。
所以，IResourceServiceProvider诞生了。
新增的resource参数帮助定位不同的资源，以便获取不同的实现。通过这样的设计，你将解决上面的问题。