在我们的项目架构中，数据库访问通常是用entity framework（EF），另外有一个很重要的service层，主要用于跟EF交互，也会在这一层封装大部分的业务逻辑。通常情况下，我们会用一个接口将某个service的成员提出来，然后通过IOC获取该service的实现。
由于service层主要为UI层提供服务，为了让调用者直接的看到可用的方法，因此往往某个service会包含某个模块的所有方法和属性，于是这个service会变得非常庞大。举个例子，比如我们有一个IProductService，用于为product模块提供数据服务。这个product模块下面包含多个子模块，比如该product的各种统计数据，销售，订单，跟踪信息等。这样一来，这个IProductService下面就可能有30多个方法，如果将这么多的方法写到一个文件里头，那这个文件很难不超过300行代码。
读到这里，你肯定在想我们可以把这些实现的代码分成多个块。可能首先想到的，也是我们大多数程序员正在写的，那就是#region/#endregion。 其实还有另外一个方案，那就是partial class。
使用partial class来拆分我们的service，其实只是一个太简单不过的想法，但就是这个思想上简单的进步，拯救了我多少的代码。从此，我的service类非常丰富，而service的实现根据模块或者调用者角色或者其他分配到多个partial类，每一个文件不超过300行代码，让维护变得非常简单，让代码变得易读。
其实使用partial类来拆分我们的大类不仅仅是可以用于service层，而是可以用于任何地方。
我最近新加入了一个项目组，这个项目的代码写的有些糟糕，很多类超过1000行代码，很多方法200多行代码，看到这样的代码实在不想去打开编辑，更别谈读懂其业务逻辑并维护。这个项目运行了好几年了，好几批程序员写过代码，可以说这个项目被多少程序员糟蹋得不成样子了。经过简单的分析，其实主要的问题在于service层和controller层的类文件太大，于是我安排人员用partial class进行拆分。重构后的代码别提变得多清纯了，让我们这些IT男喜欢不已。
朋友，你的项目里有大类吗？试着用partial class拆分下吧，相信你会有惊喜的。