从微软的DBML文件中我们能学到什么（它告诉了我们什么是微软的重中之重）~三 分部类是否破坏了单一职责

一 DBContext的构造方法，方法的重载

二 DBContext实例中，表实体对象是怎么被加入的

三 分部类是否破坏了单一职责

四 分部方法从另一方面定义了类型的操作规范

五 LINQ实体类中对属性的赋值，变化前与变化后SendPropertyChanging与SendPropertyChanged

六 LINQTOSQL中为我们触发了SendPropertyChanging和SendPropertyChanged，它的真正用意是什么

七 为DBContext对象应该作为其它实体操作类型的基类，并为它提供统一的提交动作

 

 

先来看一下“百度百科”对单一职责的定义： 一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。

分部类（Partial）也算是.net的一种新东西，没有记错应该是在2.0的时候出现的，MSDN上的定义是：

可以将类或结构、接口或方法的定义拆分到两个或多个源文件中。 每个源文件包含类型或方法定义的一部分，编译应用程序时将把所有部分组合起来。

我的理解是：当一个类在一个时间期间不能完成或不确定完成这个类的所有功能时，可以先将这个类定义成partial，它允许你在另一个地方去对同一个类进行补充，这种技术微软在linq to sql上大大的采用，当然，由于种种原因，这种使用被一些人看来是破坏了类的单一职责原则，其实，在我看来，这只是对同一职责的类，进行的一个补充，类要完成的还是那些事，只是原来不确定要干什么，或者怎么去干，而当它知道如何去实现时，可以定义一个partial，去完善它。linq to sql的代码由IDE自动生成，所以有些东西对于开发人员是不够的，而微软当然知道这一切，所以将它设计成partial，以便让程序员根据自己的需要对类进行补充，而不是扩展。

 1     [global::System.Data.Linq.Mapping.TableAttribute(Name = "dbo.Web_ExceptionLog")]
 2     public partial class Web_ExceptionLog : INotifyPropertyChanging, INotifyPropertyChanged
 3     {
 4 
 5         private static PropertyChangingEventArgs emptyChangingEventArgs = new PropertyChangingEventArgs(String.Empty);
 6 
 7         private string _ExceptionID;
 8 
 9         private string _FullInfo;
10 
11         private string _Senders;
12 
13         private string _HttpMethod;
14 
15         private System.DateTime _OccurTime;
16 
17        // ……

 

这是IDE自动生成的linq to sql的一个实体对象，我们希望将这个类进行补充，之后的代码如：

 1 public partial class Web_ExceptionLog : Entity.EntityBase
 2    {
 3        protected override object[] PrimaryKey
 4        {
 5            get { return new object[] { this.ExceptionID }; }
 6        }
 7 
 8        public override IEnumerable<RuleViolation> GetRuleViolations()
 9        {
10            throw new NotImplementedException();
11        }
12    }

 

所以说，分部类破坏了类型的单一职责是不准确的，就像好的东西，在不同的人手中所表现出来的力量也是不同的，道理是一样的。呵呵。