.NET框架设计—常被忽视的C#设计技巧

最新推荐文章于 2023-06-06 08:00:28 发布
最新推荐文章于 2023-06-06 08:00:28 发布
阅读量953 收藏
点赞数
分类专栏： C#

阅读目录：

  • 1.开篇介绍

  • 2.尽量使用Lambda匿名函数调用代替反射调用(走进声明式设计)

  • 3.被忽视的特性(Attribute)设计方式

  • 4.扩展方法让你的对象如虎添翼(要学会使用扩展方法的设计思想)

  • 5.别怕Static属性(很多人都怕Static在Service模式下的设计，其实要学会使用线程本地存储(ThreadStatic))

  • 6.泛型的协变与逆变(设计架构接口(Interface)时要时刻注意对象的协变、逆变)

  • 7.使用泛型的类型推断(还在为参数类型烦恼吗)

  • 8.链式编程(设计符合大脑思维习惯的处理流程)

    • 8.1.链式编程（多条件（方法碎片化）调用


  • 9.部分类、部分方法的使用(扩大设计范围)

1.】开篇介绍

本文中的内容都是我无意中发现觉得有必要分享一下的设计经验，没有什么高深的技术，只是平时我们可能会忽视的一些设计技巧；为什么有这种想法是因为之前跟一些同事交流技术的时候会发现很多设计思维被固化了，比如之前我在做客户端框架开发的时候会去设计一些关于Validator、DTO Transfer等常用的Common function，但是发现在讨论某一些技术实现的时候会被弄的云里雾里的，会自我郁闷半天，不会及时的明白对方在说的问题；

后来发现他们一是没有把概念分清楚，比如.NETFramework、C#、VisualStudio，这三者之间的关系;二是没有理解.NET中各个对象的本质含义，比如这里的特性(Attribute)，大部分人都认为它是被用来作为代码说明、标识使用的，而没有突破这个思维限制，所以在设计一些东西的时候会绕很多弯路；还有一点是很多人对C#中的语法特性分不清版本，当然我们要大概的了解一下哪些特性或者语法是C#2的哪些是C#3的，这样在我们设计东西的时候不会由于项目的版本问题而导致你无法使用设计技巧，比如扩展方法就无法使用在低于.NET3.0版本中，LINQ也无法在低于.NET3.O的版本中使用；

.NETFramework的版本不断的在升级，目前差不多5.0都快面世了；.NETFramework的升级跟C#的升级没有必然的关系，这个要搞清楚；C#是为了更好的与.NET平台交互，它提供给我们的都是语法糖，最后都是.NETCTS中的类型；就比如大家都在写着LINQ，其实到最后LINQ也就被自动解析成对方法的直接调用；

2.】尽量使用委托调用代替反射调用

委托相信大家都玩的很熟，委托的发展到目前为止是相当不错的，从原本很繁琐的每次使用委托的时候都需要定义一个相应的方法用来实例化委托，这点在后来的C#2中得到了改进，支持匿名委托delegate{…}的方式使用，再到现在的C#3那就更方便了，直接使用面向函数式的Lambda表达式；那么这样还需要反射调用对象的方法吗？（当然特殊场合我们这里不考虑，只考虑常用的场景；）当然反射不是不好，只是反射需要考虑很多性能优化方面的东西，增加了代码的复杂性，也让框架变的很重（现在都是在追求轻量级，只有在DomainModel中需要将平面化的数据抽象；），所以何不使用简单方便的委托调用呢；

注：如果你是初学者，这里的委托可以理解成是我们平时常用的Lambda表达式，也可以将它与Expression<T>结合起来使用，Expression<T>是委托在运行时的数据结构，而非代码执行路径；（兴趣的朋友可以查看本人的：LINQ系列文章）

下面我们来看一下演示代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
/*==============================================================================
  * Author:深度训练
  * Create time: 2013-07-28
  * Blog Address:http://www.cnblogs.com/wangiqngpei557/
  * Author Description:特定领域软件工程实践；
  *==============================================================================*/
using  System;
using  System.Collections.Generic;
using  System.Linq.Expressions;
using  System.Linq;
using  Infrastructure.Common.Cache;
using  Infrastructure.Common.Validator;
namespace  ConsoleApplication1.DomainModel
{
     /// <summary>
     /// Order.
     /// </summary>
     [EntityCache(10,  true )]
     [EntityValidator(ValidatorOperationType.All)]
     public  class  Order
     {
         /// <summary>
         /// Order code.
         /// </summary>
         public  string  OrderCode {  get ;  set ; }
         /// <summary>
         /// Items filed.
         /// </summary>
         private  List<Item> items =  new  List<Item>();
         /// <summary>
         /// Gets items .
         /// </summary>
         public  IEnumerable<Item> Items {  get  {  return  items; } }
         /// <summary>
         /// Submit order date.
         /// </summary>
         public  DateTime SubmitDate {  get ;  set ; }
         /// <summary>
         /// Mark <see cref="DomainModel.Order"/> Instance.
         /// </summary>
         /// <param name="orderCode">Order code. </param>
         public  Order( string  orderCode)
         {
             this .OrderCode = orderCode;
         }
         /// <summary>
         /// Sum items prices.
         /// </summary>
         /// <param name="itemUsingType">item type.</param>
         /// <returns>prices .</returns>
         public  double  SumPrices( int  itemUsingType)
         {
             double  resultPrices = 0.00;
             var  currentItems = items.GroupBy(item => item.ItemUsingType).Single( group  =>  group .Key == itemUsingType);
             if  (currentItems.Count() > 0)
             {
                 foreach  ( var  item  in  currentItems)
                 {
                     resultPrices += item.Price;
                 }
             }
             return  resultPrices;
         }
         /// <summary>
         /// Add item to order.
         /// </summary>
         /// <param name="item">Item.</param>
         /// <returns>bool.</returns>
         public  bool  AddItem(Item item)
         {
             if  (!item.ItemCode.Equals( string .Empty))
             {
                 this .items.Add(item);
                 return  true ;
             }
             return  false ;
         }
     }
}


这是一个订单领域实体，它里面引用了一个Item的商品类型；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/*==============================================================================
  * Author:深度训练
  * Create time: 2013-07-28
  * Blog Address:http://www.cnblogs.com/wangiqngpei557/
  * Author Description:特定领域软件工程实践；
  *==============================================================================*/
using  System;
namespace  ConsoleApplication1.DomainModel
{
     /// <summary>
     /// Order item.
     /// </summary>
     public  class  Item
     {
         /// <summary>
         /// Item code.
         /// </summary>
         public  Guid ItemCode {  get ;  set ; }
         /// <summary>
         /// Item price.
         /// </summary>
         public  float  Price {  get ;  set ; }
         /// <summary>
         /// Item using type.
         /// </summary>
         public  int  ItemUsingType {  get ;  set ; }
     }
}

上面代码应该没有问题，基本的订单领域模型大家都太熟了；为了保证上面的代码是绝对的正确，以免程序错误造成阅读者的不爽，所以都会有100%的单元测试覆盖率；这里我们主要使用的是Order类中的SumPrices方法，所以它的UnitTest是100%覆盖；

图1：

Order中的SumPrices方法的UnitTest代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
using  System;
using  Microsoft.VisualStudio.TestTools.UnitTesting;
using  NSubstitute;
namespace  ConsoleApplication.UnitTest
{
     using  ConsoleApplication1.DomainModel;
     /// <summary>
     /// Order unit test.
     /// </summary>
     [TestClass]
     public  class  DomainModelOrderUnitTest
     {
         /// <summary>
         /// Order sumprices using type 1 test.
         /// </summary>
         [TestMethod]
         public  void  DomainModelOrderUnitTest_SumPrices_ItemUsingTypeIs1_UnitTest()
         {
             Order testOrder =  new  Order(Guid.NewGuid().ToString());
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 10.0F });
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 15.0F });
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 20.0F });
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 30.0F });
             double  result = testOrder.SumPrices(1);
             Assert.AreEqual(result, 25.0F);
         }
         /// <summary>
         /// Order sumprices using type is 2 test.
         /// </summary>
         [TestMethod]
         public  void  DomainModelOrderUnitTest_SumPrices_ItemUsingTypeIs2_UnitTest()
         {
             Order testOrder =  new  Order(Guid.NewGuid().ToString());
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 10.0F });
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 15.0F });
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 20.0F });
             testOrder.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 30.0F });
             double  result = testOrder.SumPrices(2);
             Assert.AreEqual(result, 50.0F);
         }
     }
}


在以往我基本上不写单元测试的，但是最近工作上基本上都需要写每个方法的单元测试，而且要求是100%覆盖，只有这样才能保证代码的正确性；也建议大家以后多写单元测试，确实很有好处，我们应该把单元测试做起来；下面我们言归正传；

由于我们的Order是在DomainModel Layer中，现在有一个需求就是在Infrastructure Layer 加入一个动态计算Order中指定Item.ItemUsingType的所有Prices的功能，其实也就是说需要将我们的一些关键数据通过这个功能发送给远程的Service之类的；这个功能是属于Infrastructure中的Common部分也就是说它是完全独立与项目的，在任何地方都可以通过它将DomainModel中的某些领域数据发送出去，那么这样的需求也算是合情合理，这里我是为了演示所以只在Order中加了一个SumPrices的方法，可能还会存在其他一些DomainModel对象，然后这些对象都有一些关键的业务数据需要在通过Infrastructure的时候将它们发送出去，比如发送给配送部门的Service Interface；

那么常规设计可能需要将扩展点配置出来放在指定的配置文件里面，然后当对象经过Infrastructure Layer中的指定Component时触发事件路由，然后从缓存中读取出配置的信息执行，那么配置文件可能大概是这样的一个结构：DomainEntity名称、触发动作、方法名称、参数，DomainEntity名称是确定聚合根，触发动作是对应Infrastructure中的组件，当然你也可以放在DomainModel中；这里只关心方法名称、参数；

当然这里只演示跟方法调用相关的代码，其他的不在代码中考虑；我们来看一下相关代码：

1
2
3
4
5
6
7
8
9
using  System;
namespace  Infrastructure.Common
{
     public  interface  IBusinessService
     {
         void  SendBusinessData( object  callAuthor,  string  methodName,  object  parameterInstance);
         void  SendBusinessData<P>(Func<P,  object > callFun, P parameter);
     }
}

这是业务调用接口；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
using  System;
using  System.Reflection;
using  System.Linq;
using  System.Linq.Expressions;
namespace  Infrastructure.Common
{
     /// <summary>
     /// Business service .
     /// </summary>
     public  class  BusinessService : IBusinessService
     {
         /// <summary>
         /// Send service data interface .
         /// </summary>
         private  ISendServiceData sendService;
         /// <summary>
         /// Mark <see cref="Infrastructure.Common.ISendServiceData"/> instance.
         /// </summary>
         /// <param name="sendService"></param>
         public  BusinessService(ISendServiceData sendService)
         {
             this .sendService = sendService;
         }
         /// <summary>
         /// Send business data to service interface.
         /// </summary>
         /// <param name="callAuthor">Object author.</param>
         /// <param name="methodName">Method name.</param>
         /// <param name="parameterInstance">Method call parameter.</param>
         public  void  SendBusinessData( object  callAuthor,  string  methodName,  object  parameterInstance)
         {
             object  result =
                 callAuthor.GetType().GetMethod(methodName).Invoke(callAuthor,  new  object [] { parameterInstance });
             if  (result !=  null )
             {
                 sendService.Send(result);
             }
         }
         /// <summary>
         /// Send business data to service interface.
         /// </summary>
         /// <typeparam name="P"></typeparam>
         /// <param name="callFun"></param>
         /// <param name="parameter"></param>
         public  void  SendBusinessData<P>(Func<P,  object > callFun, P parameter)
         {
             object  result = callFun(parameter);
             if  (result !=  null )
             {
                 sendService.Send(result);
             }
         }
     }
}


这里简单实现IBusinessService接口，其实代码很简单，第一个方法使用反射的方式调用代码，而第二个方法则使用委托调用；在实现类里面还包含了一个简单的接口；

1
2
3
4
5
6
7
8
9
10
11
12
using  System;
using  System.Collections.Generic;
using  System.Linq;
using  System.Text;
using  System.Threading.Tasks;
namespace  Infrastructure.Common
{
     public  interface  ISendServiceData
     {
         void  Send( object  sendObject);
     }
}

目的是为了方便单元测试，我们来看一下单元测试代码；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
using  System;
using  Microsoft.VisualStudio.TestTools.UnitTesting;
using  Infrastructure.Common;
using  ConsoleApplication1.DomainModel;
using  NSubstitute;
namespace  Infrastructure.Common.UnitTest
{
     [TestClass]
     public  class  InfrastructureCommonBusinsessServiceUnitTest
     {
         [TestMethod]
         public  void  InfrastructureCommonBusinsessServiceUnitTest_BusinessService_SendBusinessData()
         {
             Order order =  new  Order(Guid.NewGuid().ToString());
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 10.0F });
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 15.0F });
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 20.0F });
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 30.0F });
             ISendServiceData mockISendServiceData = Substitute.For<ISendServiceData>();
             object  sendresult =  null ;
             mockISendServiceData.When(isend => isend.Send(Arg.Any< object >())).Do(callinfo => sendresult = callinfo.Arg< object >());
             BusinessService testService =  new  BusinessService(mockISendServiceData);
             testService.SendBusinessData(order,  "SumPrices" , 1);
             Assert.AreEqual(( double )sendresult, 25);
         }
         [TestMethod]
         public  void  InfrastructureCommonBusinsessServiceUnitTest_BusinessService_SendBusinessDataGen()
         {
             Order order =  new  Order(Guid.NewGuid().ToString());
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 10.0F });
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 15.0F });
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 20.0F });
             order.AddItem( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 2, Price = 30.0F });
             ISendServiceData mockISendServiceData = Substitute.For<ISendServiceData>();
             object  sendresult =  null ;
             mockISendServiceData.When(isend => isend.Send(Arg.Any< object >())).Do(callinfo => sendresult = callinfo.Arg< object >());
             BusinessService testService =  new  BusinessService(mockISendServiceData);
             testService.SendBusinessData<Order>(ord => {  return  ord.SumPrices(1); }, order);
             Assert.AreEqual(( double )sendresult, 25);
         }
     }
}

在第二个单元测试方法里面我们将使用Lambda方式将逻辑直接注入进BusinessService中，好就好这里；可以将Lambda封进Expression<T>然后直接存储在Cache中或者配置中间，彻底告别反射调用吧，就好比委托一样没有人会在使用委托在定义个没用的方法；(所以函数式编程越来越讨人喜欢了，可以关注一下F#；)总之使用泛型解决类型不确定问题，使用Lambda解决代码逻辑注入；大胆的尝试吧，将声明与实现彻底分离；

(对.NET单元测试有兴趣的朋友后面一篇文章会详细的讲解一下如何做单元测试，包括Mock框架的使用；)


3】被忽视的特性(Attribute)设计方式

大部分人对特性的定义是代码的“数据注释”，就是可以在运行时读取这个特性用来做类型的附加属性用的；通常在一些框架中对DomainModel中的Entity进行逻辑上的关联用的，比如我们比较熟悉的ORM，都会在Entity的上面加上一个类似 [Table(TableName=”Order”)] 这样的特性声明，然后再在自己的框架中通过反射的方式去在运行时差找元数据找到这个特性，然后就可以对附加了这个特性的类型进行相关的处理；

这其实没有问题，很正常的设计思路，也是比较通用的设计方法；但是我们的思维被前人固化了，难道特性就只能作为代码的声明吗？问过自己这个问题吗？

我们继续使用上面2】小结中的代码作为本节演示代码，现在我们假设需要在DomainModel中的Entity上面加上两个特性第一个用来断定它是否需要做Cache，第二个用来确定关于Entity操作验证的特性；

看代码：

1
2
3
4
5
6
7
/// <summary>
     /// Order.
     /// </summary>
     [EntityCache(10,  true )]
     [EntityValidator(ValidatorOperationType.All)]
     public  class  Order
     {}

代码应该很明了，第一EntityCache用来设计实体的缓存，参数是缓存的过期时间；第二个特性EntityValidator用来设置当实体进行相关处理的时候需要的验证类型，这里选择是所有操作；

现在的问题是关于特性的优先级，对于Order类的处理到底是先Cache然后验证，还是先验证然后Cache或者说内部没有进行任何的逻辑处理；如果我们将特性的视为代码的标识而不是真正的逻辑，那么对于优先级的处理会比较棘手，你需要设计如何将不同的特性处理逻辑关联起来；比较合理的设计方法是特性的处理链表；本人之前设计过AOP的简单框架，就遇到过对于特性的优先级的处理经验，也是用的链表的方式将所有的特性按照顺序串联起来然后将对象穿过特性内部逻辑，这也符合DDD的中心思想；

下面我们来看代码：

1
2
3
4
5
6
7
8
9
Codeusing System;
namespace  Infrastructure.Common
{
     [AttributeUsage(AttributeTargets.Class)]
     public  abstract  class  EntityOperation : Attribute
     {
         protected  EntityOperation NextOperation {  get ;  set ; }
     }
}


我们抽象出所有的处理，然后在内部包含下一个处理逻辑的特性实例；然后让各自的Attribute继承自它；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
using  System;
using  System.Collections.Generic;
using  System.Linq;
using  System.Text;
using  System.Threading.Tasks;
namespace  Infrastructure.Common.Cache
{
     [AttributeUsage(AttributeTargets.Class)]
     public  class  EntityCache : EntityOperation
     {
         public  EntityCache( int  cacheTime,  bool  IsEnable)
         {
             this .ExpireTime = cacheTime;
         }
         public  int  ExpireTime {  get ;  set ; }
     }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
using  System;
using  System.Collections.Generic;
using  System.Linq;
using  System.Text;
using  System.Threading.Tasks;
namespace  Infrastructure.Common.Validator
{
     public  enum  ValidatorOperationType
     {
         Insert,
         Delete,
         Update,
         Select,
         All
     }
     [AttributeUsage(AttributeTargets.Class)]
     public  class  EntityValidator : EntityOperation
     {
         public  EntityValidator(ValidatorOperationType validatorType)
         {
         }
     }
}


根据特性在类的先后顺序就可以控制他们的优先级；

图2：

2

上图很直观的表现了链表设计思想，再通过仔细的加工应该会很不错的；

4】扩展方法让你的对象如虎添翼（要学会使用扩展方法的设计思想）

扩展方法我们用的应该不算少的了，在一些新的框架中到处都能看见扩展方法的优势，比如：ASP.NETMVC、EntityFramework等等特别是开源的框架用的很多；

那么我们是不是还停留在原始社会，应该尝试接受新的设计思想，尽管一开始可能不太适应，但是当你适应了之后会让你的设计思想提升一个境界；

下面我们还是使用上面的演示代码来进行本节的代码演示，现在假如有一个这样的需求，为了保证DomainModel的完全干净，我们在应用层需要对领域模型加入一些非业务性的行为，这些行为跟DomainModel本身没有直接关系，换句话说我们这里的Order聚合实体可能需要一个获取Order在Cache中存活了多长时间的方法；那么在以往我们可能提供一个方法然后把Order实例作为参数这样来使用，但是这里我们的需求是该方法是Order对象的方法而不是其他地方的方法；

所以这里使用扩展方法就可以在不改变对象本身业务逻辑的情况下扩展对象行为；最关键的是扩展方法为后面的链式编程提供了基石；从长远来看DomainModel将会被独立到ThreadProcess总，当系统初始化时部分的DomainModel将直接主流在内存中，然后通过系统本地化将扩展方法加入，这样就可以在不改变对象的情况下添加行为，这也为行为驱动设计提供了好的技术实现；

用纯技术性的假设没有说服力，上面说给领域本身加上获取Cache的方法，肯定会有朋友说这完全没有必要，提供一个简单的方法就OK了，恩 我觉得也有道理，那么下面的需求你将不得不说妙；

【需求简述】：对象本身的行为不是固定不变的，尤其我们现在设计对象的时候会将对象在全局情况下的所有行为都定义在对象内部，比如我们正常人，在不同的角色中才具有不同的行为，我们只有在公司才具有“打开服务器”的行为，只有在家里才可以“亲吻”自己的老婆的行为；难道我们在设计User类的时候都将这些定义在对象内部吗？显然不符合逻辑，更不符合面向对象设计思想，当然我们目前基本上都是这么做的；

（有兴趣的朋友可以参考：BDD（行为驱动设计）、DCI（数据、上下文、交互）设计思想；）

现在我们来为Order添加一组行为，但是这组 行为只有在某些场景下才能使用，这里只是为了演示而用，真要在项目中设计还需要考虑很多其他因素；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
namespace  DomainModelBehavior.Order.ShippingBehavior
{
     using  ConsoleApplication1.DomainModel;
     public  static  class  OrderBehavior
     {
         public  static  Order TaxRate( this  Order order)
         {
             return  order;
         }
     }
}
namespace  DomainModelBehavior.Order.ShoppingCart
{
     using  ConsoleApplication1.DomainModel;
     public  static  class  OrderBehavior
     {
         public  static  Order Inventory( this  Order order)
         {
             return  order;
         }
     }
}


这里有两个位于不同namespace中的行为，他们对应不同的场景；第一个TaxRate用来计算税率的行为，只有在Order对象已经处于提交状态时用的；那么第二个行为Inventory用来计算库存的，用户在Shoppingcart的时候用来确定是否有足够的库存；当然这里我只是假设；

然后我们就可以在不同的场景下进行命名空间的引用，比如我们现在Shoppingcart阶段将不会使用到TaxRate行为；

1
2
3
4
5
6
7
8
9
10
11
12
13
using  System;
namespace  ConsoleApplication1
{
     using  DomainModelBehavior.Order.ShoppingCart;
     class  Program
     {
         static  void  Main( string [] args)
         {
             DomainModel.Order order =  new  DomainModel.Order(Guid.NewGuid().ToString());
             order.Inventory();
         }
     }
}

例子虽然有点简单，但是应该能说明扩展方法的基本使用方式，对于DCI架构的实现会复杂很多，需要好好设计才行；

5】别怕Static属性(很多人都怕Static在Service模式下的设计，其实要学会使用线程本地存储(ThreadStatic))

很多时候我们在设计对象的时候，尤其是面向Context类型的，很希望能通过某个静态属性直接能拿到Context，所以会定义一个静态属性用来保存对象的某个实例；但是会有很多人都会排斥静态属性，动不动就说性能问题，动不动就收多线程不安全等等借口，难道静态属性就没有存在必要了嘛；

不用静态属性你哪来的ASP.NET中的CurrentContext直接，如果怕因为多线程问题导致数据不完整，建议使用线程本地存储；没有什么好怕的，多用就熟悉了；用也很简单，直接在静态属性上面加上这个特性就OK了，前提是你已经考虑了这个属性是线程内部共享的不是应用程序级别的共享；


1
2
3
4
5
/// <summary>
/// 数据源的操作
/// </summary>
[ThreadStatic]
private  static  IDataSourceOperation datasourceoperation = IDataSourceOperationFactory.Create();

6】泛型的协变与逆变(设计架构接口(Interface)时要注意对象的协变、逆变)

越来越多的人喜欢自己捣鼓点东西出来用用，这很不错，时间长了设计能力自然会得到提升的；但是最近发现我们很多泛型在设计上缺乏转换的控制，也就是这里的协变和逆变；我们有一个Item类型，现在我们需要对它进行更加具体化，我们派生出一个Apple类型的Item；

1
2
List<Apple> apples =  new  List<Apple>();
List<Item> items = apples;

这段代码是编译不通过的，因为List<T> 在定义的时候就不支持逆变、但是如果换成下面这样的代码是完全可以的；

1
2
List<Apple> apples =  new  List<Apple>();
IEnumerable<Item> items = apples;

很容易的就可以得到集合的转换，虽然很简单的功能但是在设计上如果运用好的话能大大改变接口的灵活性；你可能会有一个疑问，为什么具体实现List<T>不支持协变而IEnumerable<out T>反而支持协变；这就是面向对象设计的思想，接口本质是抽象的，抽象的不会有具体的实现所以它作为协变不会存在问题，但是逆变就会有问题；


7】使用泛型的类型推断(还在为参数类型烦恼吗)

在设计泛型方法的时候要学会使用类型推断技巧，这样会很方便的在调用的时候减少你显示调用<>的代码，也会显得很优美；大家应该都比较熟悉Func泛型委托，它是C#3中的主角，也是函数式编程的基础，我们在设计某个方法的时候会将逻辑暴露在外部，然后通过Lambda的方式注入进来；现在的LINQ都是这么实现的，比较熟悉的Where方法、Select方法，都需要我们提供一个作为它内部逻辑的函数段；

1
2
3
4
5
6
7
List<Item> items =  new  List<Item>();
             items.Add( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 20 });
             items.Add( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 20 });
             items.Add( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 20 });
             items.Add( new  Item() { ItemCode = Guid.NewGuid(), ItemUsingType = 1, Price = 20 });
             items.Where<Item>(item => item.ItemUsingType == 1);
             items.Where(item=>item.ItemUsingType==1);

这里有两种调用Where的代码，哪一种看上去舒服一点有没一点，不用我说了；那我们看一下它的定义：

1
public  static  IEnumerable<TSource> Where<TSource>( this  IEnumerable<TSource> source, Func<TSource,  bool > predicate);

我们看到TSource类型占位符，很容易理解，这是一个扩展IEnumerable<TSource>类型的方法，系统会自动的匹配TSource；我们在设计的时候也要借鉴这种好的设计思想；

（有兴趣的朋友可以参见本人的：.NET深入解析LINQ框架（一：LINQ优雅的前奏））

8】链式编程(设计符合大脑思维习惯的处理流程)

其实那么多的C#新特性都是为了能让我们编写代码能更方便，总之一句话是为了更符合大脑思维习惯的编程模式；

C#从纯面向对象渐渐的加入了函数式模式，从静态类型逐渐加人动态类型特性；C#现在变成多范式编程语言，其实已经很大程度满足我们的日常需求；以往我们都会为了动态行为编写复杂的Emit代码，用很多CodeDom的技术；现在可以使用Dymanic解决了；

这节我们来看一下关于如何设计线性的链式方法，这不是技术问题，这是对需求的理解能力；可以将链式思想用在很多地方，只要有逻辑有流程的地方都可以进行相关设计，首先你要保证你是一个正常思考问题的人，别设计出来的方法是反的，那么用的人会很不爽的；这里我举一个我最近遇到的问题；

8.1】链式编程（多条件（方法碎片化）调用

我们都熟悉DTO对象，它是从UI传过来的数据集合，简单的业务逻辑Application Layer将它转换成DomainModel中的Entity，如果复杂的业务逻辑是不能直接将DTO进行转换的；但是在转换过程中我们总是少不了对它的属性判断，如果UserName不为空并且Password不为空我才能去验证它的合法性，等等；类似这样的判断；这里我们将运行扩展方法将这些逻辑判断链起来，并且最后输出一个完整的Entity对象；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using  System.Collections.Generic;
namespace  ConsoleApplication1
{
     public  static  class  DtoValidator
     {
         public  static  IEnumerable<TSource> IsNull<TSource>( this  IEnumerable<TSource> tList)
         {
             return  tList;
         }
         public  static  IEnumerable<TSource> IsLength<TSource>( this  IEnumerable<TSource> tList,  int  max)
         {
             return  tList;
         }
         public  static  IEnumerable<TResult> End<TResult>( this  IEnumerable< object > tList, IEnumerable<TResult> result)
         {
             result =  new  List<TResult>();
             return  result;
         }
     }
}

有一组扩展方法，用来做验证用的；

1
2
3
List<Order> orderList =  null ;
List<Dto.OrderInfoDto> dtoList =  new  List<Dto.OrderInfoDto>();
dtoList.IsNull().IsLength(3).End(orderList);

由于时间关系我这里只是演示一下，完全可以做的很好的，在判断的最后拿到返回的列表引用最后把数据送出来；

（有一个开源验证框架应该还不错，目前工作中在用：FluentValidator）

9】部分类、部分方法的使用(扩大设计范围)

部分类不是新的特性，而部分方法是新特性；我们通过灵活运用部分类可以将发挥很大作用，比如我们完全可以将类的部分实现完全隔离在外部，起到低耦合的作用，甚至可以将声明式设计和元编程运用在C#中，比较经典就是ASP.NET后台代码和前台的模板代码，在运行时然后再通过动态编译合起来，我们不要忘记可以使用部分类、部分方法来达到在运行时链接编译时代码和运行时代码，类似动态调用的效果；

由于这部分内容比较简单，是设计思想的东西，所以没有什么要演示的，只是一个总结；


总结：内容虽然简单，但是要想运用的好不简单，这里我只是总结一下，希望对大家有用，谢谢；


示例DEMO地址：http://files.cnblogs.com/wangiqngpei557/ConsoleApplication1.zip

五维思考
关注
专栏目录
.NET框架设计（常被忽视的C#设计技巧）
dengzai7446的博客
07-29 602
阅读目录： 1.开篇介绍 2.尽量使用Lambda匿名函数调用代替反射调用(走进声明式设计) 3.被忽视的特性(Attribute)设计方式 4.扩展方法让你的对象如虎添翼(要学会使用扩展方法的设计思想) 5.别怕Static属性(很多人都怕Static在Service模式下的设计，其实要学会使用线程本地存储(ThreadStatic)) 6.泛型的协变与逆变(设计架构接...
c#设计一个方法,与使用
while(True): print('adorable')
06-24 178
1.普通方法与静态方法. 普通方法 用会分配空间,不用则毁. public void Method1() {} 静态方法 static void Method1() {} 无论你是否使用,都会占用内存,性能变能. 2.语法: 访问修饰符[其它修饰符] 返回值类型 方法名([参数列表]) { 方法体[返回值return] //面向过程的代码 } 3.面向对象的最大特点是有类,有方法,只要实例化...
C#程序设计经典教程
ca1m4n的博客
01-14 4470
复习周还睡？ 从数据存储角度数据可分为值类型和引用类型。值类型主要有三种：简单类型、枚举类型、结构类型。 字符串方法 Replace，替换 Split，转换为字符串数组 Substring，求子串 Trim，去掉首尾空格 switch语句一定要有break，break中止当前循环,continue中止本次循环，继续下一次循环 ...
使用c#实现23种常见的设计模式
dotNET跨平台
06-06 326
使用c#实现23种常见的设计模式设计模式通常分为三个主要类别：创建型模式结构型模式行为型模式。这些模式是用于解决常见的对象导向设计问题的最佳实践。以下是23种常见的设计模式并且提供c#代码案例：创建型模式：1. 单例模式（Singleton）publicsealedclassSingleton { //创建一个只读的静态Singleton实例 privatestaticr...
C#的架构、框架、设计模式
热门推荐
就随便写写....
07-29 1万+
包含两层架构、三层架构、接口、反射，以及基于这些技术的简单工厂模式和抽象工厂模式的实现
基于.net下C#开发的物业管理信息系统（源码）含系统设计解决方案文档.zip
07-11
《基于.NET下C#开发的物业管理信息系统》是一个深入实践的软件开发项目，它结合了.NET框架和C#编程语言，旨在构建一个高效、便捷的物业管理工具。本系统的设计与实现涵盖了多个IT领域的关键知识点，包括但不限于...
C# .NET工控上位机开发
06-04
在工控领域，C# .NET技术被广泛用于构建上位机软件，它以其强大的功能、易用性和高效的性能成为了开发者的重要工具。本文将详细探讨C# .NET在工控上位机开发中的应用，以及相关的核心知识点。 一、C#语言基础 C#是...
ASP.NET+SQL网上校友录设计与实现(源代码+论文).rar
11-08
1. **ASP.NET框架**：ASP.NET是微软开发的一种服务器端Web应用程序框架，它支持Web Forms、MVC、Web API等多种开发模式。在这个校友录项目中，ASP.NET被用来构建用户交互界面，处理HTTP请求，以及管理页面间的生命...
ASP.NET基于局域网的信息收发系统的设计与实现(源代码+论文).rar
11-08
ASP.NET是一种由微软开发的服务器端Web应用程序框架，主要用于构建动态网站、Web应用程序和服务。它构建在.NET Framework之上，提供了一种高效的编程模型，支持多种编程语言，如C#、VB.NET等。在这个"ASP.NET基于...
ASP.NET 开发人才招聘系统设计(源代码+论文)
最新发布
03-22
首先，该系统的开发涉及到的主要技术栈包括C#编程语言、ASP.NET MVC框架以及可能用到的SQL Server数据库。C#是.NET Framework的主要编程语言，具有类型安全、面向对象的特点，适合构建大型企业级应用。ASP.NET MVC...
创建者模式（设计模式，分层清晰，逻辑明显）
04-08
本例是一个分层次的实例，里面简单清晰的逻辑说明了设计模式之---创建者模式
C#/.Net企业级系统架构设计实战精讲教程
12-03
课程通过实际项目融入常用开发技术架构，讲授风格独特，提供详细上课日志及答疑，赠送配套的项目架构源码注释详细清晰且表达通俗，均能直接在实际项目中应用，正真的物超所值，价格实惠任务作业：综合运用《C#/.Net企业级系统架构设计实战精讲教程》课程所学知识技能设计一个学生成绩管理系统的架构。要求：1.系统基于MVC的三层架构，各层单独建不同的解决方案文件夹。2.采用Model First开发方式，设计架构时只需要设计学生表（TbStudent）和课程表（TbCourse）。学生表必须有的字段是ID、stuName、age；课程表必须有的字段是ID、courseName、content。3.数据访问层采用Entity Framework或NHibernate来实现，必须封装对上述表的增删改查方法。4.必须依赖接口编程，也就是必须要有数据访问层的接口层、业务逻辑层的接口层等接口层。层层之间必须减少依赖，可以通过简单工厂或抽象工厂。5.至少采用简单工厂、抽象工厂、Spring.Net等技术中的2种来减少层与层之间的依赖等。6.封装出DbSession类，让它拥有所有Dal层实例和SaveChanges方法。7.设计出数据访问层及业务逻辑层主要类的T4模板，以便实体增加时自动生成相应的类。8.表现层要设计相关的控制器和视图来验证设计的系统架构代码的正确性，必须含有验证增删改查的方法。9.开发平台一定要是Visual Studio平台，采用C#开发语言，数据库为SQL Server。10.提交整个系统架构的源文件及生成的数据库文件。（注意： 作业需写在CSDN博客中，请把作业链接贴在评论区，老师会定期逐个批改~~）
C#基础篇之C#和 .Net框架的概念和运行原理
我还是个孩子的博客
06-13 4805
 引言：要使用一样东西，最起码得对他有个最基本的了解，所以，熟悉一下概念和流程还是非常有必要的，下面一起来看看吧！一、微软平台的发展史二、.Net框架包含的东西1、名词解释  BCL：基类库（Base Class Library）系统和底层提供的最基本的类库  CLR：公共语言运行时(Common Language Runtime)    CLS：公共语言规范(Common Language Sp...
DCI：DCI学习总结
weixin_33816611的博客
09-05 1517
备注 之前把DCI的Role和四色原型的Role给弄混了，本文也不会比较这两种Role的区别（后面有机会再说），这里简单的记录一下对DCI的理解。 参考文章：http://www.cnblogs.com/happyframework/p/3302238.html。 什么是DCI？ Context 选择 Data，让 Data  扮演 Role 执行 Interaction。 Data...
可悲的外企Infrastructure - 些须感触（杂）
weixin_30663391的博客
06-09 458
做IT的人都知道，做ERP的定位比做Infrastructure的高，Infrastructure简单的来说，大公司的就是coordinator，小公司的，那就是网管了。 为什么说外企的Infrastructure可悲？ 自身的因素是一点，能力不够。另外一点也是客观存在的，那就是很多外企会把DC放在国外，国内只留一个“听话”的执行者就可以了，技术得不到提高，自然工资也就高不到那里去了。很多人或...
最新收集的.net文章 更新时间:2005-9-8
weixin_30904593的博客
09-08 158
最新收集的网络编程 更新时间:2005-9-8C#多线程共享数据使用C#编写Ice应用程序使用C#在进度条中显示复制文件的进度用C#给程序加启动画面并只允许一个应用程序实例运行C#编码规范.docC#数据库连接字符大全C#读写注册表用C#实现WEB浏览器C#:ListBox的2个常用方法Add,Clear与Items的2个属性以实例说明如何使用C#从数据库中提取数据，按要求自动生成定制的Excel...
C#实现的.NET图书借阅管理系统毕业设计源码
系统采用了.NET框架，以C#作为主要开发语言，利用了.NET平台的高效性和稳定性。 在该系统的设计与实现中，涉及到了多个关键知识点和技术细节。首先，了解.NET框架的基本原理是开发此类系统的前提。.NET框架是微软...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值