高效率地开发，不仅仅需要技术，还需要的是一些现实的技巧，相对.NET Framework 1.1中的C#来说，语言中提供的partial关键字，可以说是一个伟大的创举，在真实的业务开发中，很多时间会遇到各类不同的函数归类整理的问题，尽管在VS.NET IDE中有伟大的IDE标志#regoin...#endregion可以很好地进行分类，但它仍然不是一个理想的模式，很多时候，在只有内部业务处理的情况下，我们更加乐意在一个类里完成所有的功能，而并不想通过创建一系列的命名空间中包括一堆public函数来实现．
　　这个现实情况也许从纯情的对象化思想来看并不完美，但实际上有很多因素让人郁闷，比较说，比较好的代码辅助工具CodeRush，它的颜色大量渲染造成了IDE速度地变慢，在一个有上万行代码的文件中，打开的速度是非常令人郁闷的．有人也许会说，怎么会有上万行代码，难道不能把它们给处理一下吗？分割成多个文件．这个想法好，但要是在古代没有partial class的时期，这就会产生大量的问题：新创建的文件类命名为什么？是否合理？代码分割后，很多地方的代码要修改为"类名.方法＂的形式，能保证对源代码的修改是安全可靠的吗？创建一个这样一个在系统意义上来说没有单独存在价值的类是否有必要？
　　有一些人乐意把其中的可重用函数提炼出来，形成一个新的类，作为一个单独类的使用，这是无可厚非的，但是，如果要是遇到一堆逻辑是属于此类的方法，但是因为客观条件造成的方法太多而造成必须提炼时，应该怎么办？
　　不清楚古代的人是怎么处理的，但现代一些的方法，通过partial类不妨是一个很好的方案，大凡类似于业务单据一中的IDE接口一类的，在一个part中，然后此单据不同的逻辑业务就在不同的逻辑中，这样的好处主要在于效率，不要指望类设计者一开始就考虑好代码量并且能够给你设计足够的类来实现，就现实开发来说，没有哪个公司有足够强力的设计者能细致到函数级别地提供设计结构给你，所以最中间的洽入点就是，设计者通过分析师给出来的要求设计出系统结构，并规划好大致的类及主要的公共调用函数之后，内部的黑盒开发应该是由开发者即程序员自己来决定函数的取舍．
　　就以前我从事过的项目经验来说，把类这一步化成了命名空间，分派命名空间及规定的必定实现公共类后，其它的任程序员在命名空间中发挥--无论你怎么发挥，只要不影响我的公共调用就ＯＫ．不幸地是，尽管这类的方法是很有效率的，但造成了一个非常巨大的问题就是，命名空间太，using来using去，怎么看也不漂亮，由于命名空间被占用了，更高层次的分割就必须通过命名空间的堆积来完成，这种堆积有时还有一些副作用，比如你在ＩＤＥ中，查看命名空间时，经常会发现程序员们自己创造的一些古怪的私有空间名称，本来自由给出了无可厚非，但是，这样一来，始终觉得心里不舒服，因为如果能够看见，就容易勾引人的好奇心．
　　通过partial虽然不能解决＂你能够看见＂问题，但是它毕竟挪出了命名空间的地盘，可以使你更好地组织类与命名空间，如果没有partial，就会仅仅因为＂看起来不顺眼＂的而导致不得不放任一个命名空间给程序员．
　　partial还有一个更有趣的强大功能就是可以打造白盒式的测试驱动开发，在古老的开发中，一般测试驱动开发有两种形式，第一种是创造一个测试项目，对项目进行黑盒式处理，这样的控制很不精细，尽管微软的开发中提供了变通的私有函数的测试办法，但是个人认为那看起来＂太扭曲＂，要黑就黑，搞得模模糊糊扭扭捏捏地干嘛．第二种是白盒测试，就是在类内部通过#if..#endif预处理来对测试代码进行控制，这种好处是无须太多麻烦就可以直观地对指定成员编写测试代码，可以说是一个很精细化地控制，但是同时有一个巨大的问题就是，它这样的方法，有诸多不良因素，比如首先要在项目内引用测试专用的程序集，同时也造成了代码的凌乱，尽管#region...#endregion可以解决一部分问题，但仍然不够爽，理由同前，代码太多，ＩＤＥ就太变慢了，不利于有效率地开发．
　　partial可以部分解决这个问题，说是部分解决是因为无法解决引用程序集的问题，这是必须的，引用程序集的问题只能通过配置比如nant,msbuilt之类的来解决．partial可以解决的问题就是，可以针对每一个片断类创造一个Test用例类，并用预定义指令进行修饰，在类的结构列表中，命名上有一个小技巧就是不要再命名成"test＿methodname"的形式，而应该用"methodname_test"的形式，这样一来，许多事情就好办了，在类的浏览列表中，由于按字母排序，很轻易就可以看出，哪一些函数有了测试用例，哪一些函数没有,非常方便．