一、场景驱动设计原则
设计框架时因该把注意力集中在一些常用场景，使整个设计过程由场景来驱动。场景分为常用场景和高级场景。（“场景”即用户使用Framework进行开发，调用API的情景）
在设计框架时，必须从一组使用场景以及实现这些场景的样例代码开始。
要为每个主要的特性域（feature area）定义一些最常用的场景 。
要确保使用场景与适当的抽象层次相对应。场景应该大致与最终的用户用例相对应。（为场景定义合适的粒度，不要过于细粒度）
在设计API时：先应该为主要场景编写样例代码 （即开发人员使用Framework时，调用API实现某一功能的代码）；然后在定义对象模型去支持这些样例代码。
二、低门槛原则
框架必须以易于实验的方式，为普通用户提供一个低门槛。
要确保每个主要特性的命名空间只包含那些最常见的场景类型。应该把更高级的场景类型放于子命名空间中 。比如System.Net与Sytem.Net.Sockets。
要为构造函数和方法提供简单的重载函数。一个简单的的重载函数不仅参数数量非常少，且所有参数都是基本类型。
不要在为主要的使用场景而设计的类型中，包含高级场景的方法。
不要要求用户在最基本的使用场景中显式的实例化一个以上的类型。
不应该让用户进行很多初始化操作或是实例化许多类型把它们连接起来。不要要求用户在为基本使用场景写代码之前就进行大量的初始化。理想情况下，如果类型 是为基本场景而设计的，那么使用默认的或者是只带一个简单参数的构造函数就足以开始工作了。如果有一些初始化是必须的，那么当用户由于示执行初始化而引起 异常时，应该在异常消息中清楚告诉用户需要做些什么。
要尽可能地为所有的属性和参数提供合适的默认值。
要通过异常来传达对API的误用。
三、自说明对象模型原则
1、命名
不必担心标识符的名字太长。
把最好的名字留给最常用的类。
2、异常
要通过异常告诉用户对框架的误用。
四、分层架构的原则
对框架进行分层，使得通够对框架进行不同程度的控制。
分层设计使得在单个框架可以同时提供强大的功能和易用性。
为用户建立单个框架的一般规范是： 把API划分为低层类型和高层类型，让低层类型暴露丰富的API并提供强大的细粒度功能，而高层次类型则实现对低层次API的封装，对外提供简便的粗粒度功能API。
两种主要的方法为API划分命名空间：
（1）在单独的命名空间中暴露层（大多数框架都应该遵循这个命名空间的划分方法）
把高层次类型和低层次类型放在虽然不同，但是有联系的的命名空间中。这种方法优点在于，既可以把低层次类型从主要场景中隐藏起来，又不会让开发人员在需要实现更复杂的场景时找不到。
（2） 在相同的命名空间中暴露层
这种方法的优点在于可以在需要的时候自动使用更复杂的功能。缺点在于复杂类型放在同一个名字空间会使某些用场景更加困难。
考虑对框架进行分层，使高层API提供最佳的开发效率，低层API提供最强大的功能和最丰富的表现力。
避免把低层API和高层API混在同一个命名空间中。
要确保单个特性域中不同的层能很好的集成在一起。用户开始时，使用其中一个层次进行开发，通过修改代码就可以用另一层。