依赖（dependency）：指两个不同的实体间的一种联系。
例：A程序集依赖B程序集。则称A是B的客户（client），B是A的服务（service）
引用（Reference）:引用程序集建立依赖关系。
依赖管理：
1、实现与接口：接口的所有客户端都不应该知道接口的具体实现方法。
2、new代码味道（code smell）接口描述能做什么，接口的实现类描述如何做，只有类才能涉及接口实现的具体细节。（代码味道：如果某段代码可能存在问题，就可以说有代码味道。使用new关键字创建对象实例属于“狎昵关系（两个类之间的关系过于亲密，即关联到一起）”，因为构造函数属于实现细节，客户端调用构造函数可能引入意外的依赖关系（引入隐藏的程序集））
3、缺乏可测试性：可测试性需要代码以一定的模式构建。如果不这样做，测试将变得极其困难。（即无法使用不执行任何动作的模拟实现来替代这两个类的实现）
4、更多的狎昵关系：在A类中实现了B类。如果调用B类中的方法时，B类方法中创建了C类，则A类与C类存在狎昵关系，导致出现更多的狎昵关系。
对象构造的替代方法：
1、针对接口编码：将B类中的功能提取出一个接口，A类只依赖B类中的接口而不是B类的具体实现。
2、使用依赖注入（Dependency Injection）：修改A类的构造函数，构造函数传入B类的接口而不是B类创建的对象。这样管理依赖的能力会提高很多。（需要客户端代码提供一个B类的接口的实现，将A类与B类完全解耦）
随从反模式（entourage anti-Pattern）：
需要一个程序集中的一个功能，但是会引入这个程序集中很多其他不需要的东西。所以接口和接口的依赖项不应该布置在同一个程序集内。
阶梯模式：
阶梯模式是一种正确组织类和接口的方法。因为接口和接口的实现类布置在不同的程序集内，二者可以独立更改，客户端代码始终只需要引用接口所在的程序集。
好处：接口没有任何依赖。调用接口的客户端代码也不会有任何的隐藏依赖，接口的实现也同样只依赖其他仅包含接口的程序集。接口的方法和属性不应当暴露出任何第三方引用中定义的数据对象或类。
依赖解析：
程序集：公共语言运行时（Common Language Runtime CLR）使用即时（just-in-time JIT）模式来解析程序集。只有首次使用程序集中的某个特性时才会解析应用中包含的引用。
服务：与程序集相比，客户端和服务之间的耦合关系更加松散。
1、已知端点：如果客户端代码编译时就知道服务位置，可以为客户端创建一个服务代理。两种创建代理的方式：1、VS自带的为项目添加服务引用。优点：节省实现。缺点：缺乏代码控制。2、使用ChannelFactory类编码创建服务代理。（最好用于客户端代码能够方位服务接口并且可以通过引用重复使用时）
2、服务发现：两种方式 托管的和自组网的。
3、Rest化服务（REpresentational State Transfer 表述性状态转移）：客户端几乎没有任何依赖，只需要一个所有语言的框架和库都体用Http client实例。适合开发需要跨平台的功能强大的服务。