[10/26/11 10:10:16.011],[35],ERROR,”Encountered an unhandled thread exception: System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was ’10675199.02:48:05.4775807′. —> System.IO.IOException: The read operation failed, see inner exception. —> System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was ’10675199.02:48:05.4775807′. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host 

这个issue比较怪异，网上google了一大圈，遇到此类问题的童鞋还真不少。不过解决方法，提到的是放弃使用netTcpBinding，采用HttpBinding或者其他方式的binding即可解决。也没说具体是啥原因，不过，最后终于在Microsoft的网站上找到了答案，原来Microsoft承认这是.NET Framework的bug。并且提供了一个hot  fix供下载，hot fix是针对.NET 3.5的，而这个bug貌似在.NET Framework 4.0中也会遇到。因为我们公司的项目就是.NET 4.0的⋯⋯

有人在微软的网站反馈了此问题，帖子在这里：http://connect.microsoft.com/wcf/feedback/details/622164/wcf-servicehost-crashes-when-usernamepasswordvalidator-takes-too-long-to-process

微软提供的hot fix地址：http://support.microsoft.com/kb/2600907

不过针对.NET 4.0的hot fix，不知道是微软没出，还是仍旧在解决中⋯⋯ 反正帖子里面的答复，是说会在下一个版本的.NET Framework中解决，难道是.NET 5.0中么？ 汗⋯⋯

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

仔细分析了下这个异常，应该是传递大数据造成的，因为在回传一个包含有100多个实体对象的列表时，客户端表现正常，而当回传的实体对象列表数目达到500+时，异常就出现了。

其实WCF还是做得比较灵活的，基本所有的配置项都放在程序的app.config文件里面，改动相应参数时，不需要重新编译程序。而WCF设计的初衷，为了避免DOS一类的攻击，默认在生成配置文件时，对传输的buffer数值有一定的限制，默认是65535，也就是64KB。然而在一些特定的应用场景中，区区64KB的buffer是不能满足我们需要的。这就需要我们手动在配置文件中调整buffer的size。

在配置文件中需要调整的一些参数，大致有下面几种：

WCF binding中的maxBufferSize, maxReceivedMessageSize
WCF binding ReaderQuotas中的maxArrayLength, maxBytesPerRead, maxDepth等

在一些比较极端的场景中，我们可以把它设到最大2147483647，也就是约等于2GB大小的buffer。嗯，我想，除非你是用WCF来传输1080P的高清电影，否则2GB的大小能满足绝大多数情况的需求了。

后来，我在更改相关参数大小后，发现异常依然存在，这个问题还郁闷了我很久，知道第二天，才在网上找到答案。原来，WCF的服务端和客户端，如果传递的是实体对象(Entitiy Model)一类的数据，在传输中会涉及到序列化的问题，WCF中还有个针对EndPoint的配置项，里面可以设定需要序列化的对象的最大size。后来我更改了dataContractSerializer 的maxItemsInObjectGraph属性后，这个问题，才得到了圆满的解决。修改配置文件，可以参考下面的例子：

Client配置：

1
2
3
4
5

<endpointBehaviors> 
          <behavior name="ClientBehavior"> 
            <dataContractSerializer maxItemsInObjectGraph="10000000"/> 
          </behavior> 
        </endpointBehaviors>

Server配置：

1
2
3
4
5

<serviceBehaviors> 
        <behavior name="HostBehavior"> 
          <dataContractSerializer maxItemsInObjectGraph="10000000"/> 
        </behavior> 
      <serviceBehaviors>

修改后的客户端，支持和服务端传输1000+的实体对象列表，我想远远不止这个数量，上1w的对象估计都没问题。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

其实哥平时的开发中，用得比较多的，还是Reflection(反射)了，不过早已久仰Emit的大名，又没闲暇时间来窥探一把，最近总算比较闲了，决心研究研究强大的Emit。

话不多说，代码是最有力的说明，先献上一个通过Emit动态创建并生成程序集的例子：

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

using System;
using System.Reflection;
using System.Reflection.Emit;
 
namespace Emit_Learn
{
    class Program
    {
        static void Main(string[] args)
        {
            var name = new AssemblyName("HelloEmit");
            var assemblyBuilder =
            AppDomain.CurrentDomain.DefineDynamicAssembly(name,
            AssemblyBuilderAccess.RunAndSave); //创建程序集
              var modelBuilder = assemblyBuilder.DefineDynamicModule("HelloEmit",             "HelloEmit.dll"); //创建模块
              var typeBuilder = modelBuilder.DefineType("HelloEmit"); //定义类型
              var methodBuilder = typeBuilder.DefineMethod("Execute",                                 MethodAttributes.Public,                                 null,                                 null); //创建MethodBuilder
            var il = methodBuilder.GetILGenerator(); //获取ILGenerator，用于生成方法的IL
            il.Emit(OpCodes.Ldstr, "Hello, Emit");
            il.Emit(OpCodes.Call,                     typeof(Console).GetMethod("WriteLine",                     new Type[] { typeof(string) }));
            il.Emit(OpCodes.Ret);
            typeBuilder.CreateType();
            assemblyBuilder.Save("HelloEmit.dll"); //保存动态生成的程序集到磁盘文件
 
        }
    }
}

在IDE中输入以上代码，F5运行，你会发现，在你的程序的Debug目录，会生成一个HelloEmit.dll。没错，这就是我们的程序动态生成的程序集，并且它是可执行的。以上的代码，动态生成的程序集，包含一个叫HelloEmit的类，类中有一个public属性的Execute方法。方法中调用Console输出字符串：Hello,Emit

这个类，等价于如下的C#代码：

1
2
3
4
5
6
7
8

internal class HelloEmit
{
    // Methods
    public void Execute()
    {
        Console.WriteLine("Hello, Emit");
    }
}

我们也可以使用.NET Reflector一类的工具，打开生成的Dll查看，顺便验证一下。

Emit适用的场景：适用于对业务灵活性要求很高的系统，可以在运行时动态更改业务逻辑，并动态生成代码。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

下面是VS2010中的新增特性(网上copy过来的)：
·对多显示器的支持
·支持调用继承树
·新特性支持TDD
·新特性支持Office开发
·全新的Quick Search功能
·Call hierarchy高亮对象的引用
·直接使用一个未定义的对象
·提供更方便的javascript脚本编写
·HTML snippets超越智能提示
·可以进行自定义开始页
·C# 4.0的语言新特性
·提升了SharePoint开发功能
·特性聚焦：分析和调试并行应用程序
·正式包含F#函数式语言

下载完后，迫不及待开始安装：

和期望比较不一样的是，安完需要的组件，供占5个多GB的硬盘空间，还是比较苗条了。选完需要安装的组件，俺很慎重的按下了Install按钮……

漫长的安装过程，中途机器重启了两次，一次是在.NET Framework 4.0安装过后，一次是在整体安装完毕过后。

安装完毕，俺怀着激动的心情，启动了VS2010，跳出不规则的Splash Window.

整体使用感觉相当不错，此前还担心WPF实现的IDE界面会拖慢运行速度，看来这样的担心是多余的。跟VS2008相比，感觉VS2010的反应速度会快很多。看来这方面的优化还是做足了功夫的。另外，令人满意的是VS2010的扩展功能，内置的Extention Manager能够看到很多的在线扩展，选择你想要的，可以在线安装和卸载。这种方式让VS2010的扩展更加丰富和强大，值得表扬！

另外，还有很多的关于.NET Framework 4.0 以及 VS2010的新特性还没来得及体验，比如dynamic，并行编程，新版的ADO.NET Entity Framework，新引入的F#语言，等等……
无意中也发现，ReSharper 5.0 也随着VS2010的发布而发布了，看来步调相当一致啊~这款功能强大的工具，自从VS2005开始，俺就一直用，现在不装反而不习惯了。于是卸掉之前的ReSharper 4.5，升级到5.0版。ReSharper 5.0本身也支持VS2008和VS2010，这样机器上的两个IDE可以和谐共存，并同时使用ReSharpter 5.0，简直太完美了。

总体感觉：VS2010和VS2008相比，确实是一大进步，或者说，确实是个飞跃…… 打算用段时间就把VS2008从机器中清理掉，嘿嘿……

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

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

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace CommonLib
{
    public static class EntityValidator
    {
        public static ValidateResult Validate(this T target,
                                              Predicate predicate,
                                              string errorMessage)
        {
            var result = new ValidateResult(target);
 
            if (!predicate(target))
            {
                result.Errors.Add(errorMessage);
            }
 
            return result;
        }
 
        public static ValidateResult Validate(this ValidateResult target,
                                              Predicate predicate,
                                              string errorMessage)
        {
 
            if (!predicate(target.Entity))
            {
                target.Errors.Add(errorMessage);
            }
 
            return target;
        }
    }
 
    public class ValidateResult
    {
        internal List Errors { get; set; }
        internal T Entity { get; private set; }
        public bool HasErrors
        {
            get { return Errors.Count > 0; }
        }
 
        internal ValidateResult(T entity)
        {
            Errors = new List();
 
            Entity = entity;
        }
 
        public string[] ErrorMessages { get { return Errors.ToArray(); } }
    }
}

有了这个实体验证的方法，代码可以简洁多了，并且再也不用在业务逻辑判断中，写入复杂的if…else语句块，取而代之的代码，示例如下：

1
2
3
4
5
6
7
8
9
10
11
12

ValidateResult validateResult =
                        content.Validate(c => !string.IsNullOrEmpty(c.Name), "Name为空")
                               .Validate(c => c.MobilePhone.Length == 11 , "MobilePhone长度不正确")
                               .Validate(c => c.Age >= 10), "年龄不在规定范围")
                               .Validate(c => c.Height <= 200 && c.Height >= 180, "身高不符合标准");
 
                    if (validateResult.HasErrors)
                    {
                        log.Info("实体验证失败:");
                        validateResult.ErrorMessages.ForEach(p => log.Info(p));
                        return null;
                    }

怎么样？这样的链式编程的代码，比起一大串的if…else组合语句，简洁、明了多了，并且还可以提高代码阅读的效率，强烈推荐各位同学使用。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

Linq to Sql中默认采用的模式就是延迟执行，所谓延迟执行，其实就是在获取对象本身时，并不会获取和其关联的其他对象，只有在访问其关联对象的时候，程序才会去加载关联对象的数据到内存中。这样的好处是程序不会在初次访问的时候，就加载大批量的数据，而是以一种延迟加载的方式进行处理，相对而言，对于系统和网络的性能开支会减小很多。对于一个默认的Linq to Sql查询，延迟加载就是其默认的设置，不过，在某些情况下，延迟加载并非完全“智能”，不但没有实现其本意，反而增大了网络流量和性能开支。下面我们以SQL Server中的演示数据库NorthWind来试验一下：

1
2
3
4
5
6
7
8
9
10
11
12
13

LinqTestDataContext ctx = new LinqTestDataContext();
ctx.Log = Console.Out;
 
var result = ctx.Orders.Where(p => p.OrderID == 10251);
 
foreach (var t in result)
{
	Console.WriteLine("OrderID:" 
		+ t.OrderID 
		+ "-" 
		+ "OrderDate:" 
		+ t.OrderDate.Value.ToString("yyyy-MM-dd"));
}

通过Linq to sql查询所有OrderID为10251的订单信息，并输出订单编号和订单日期。通过显示Linq的日志输出，我们可以看到后台生成的SQL语句如下：

1
2
3
4
5
6

SELECT [t0].[OrderID], [t0].[CustomerID], [t0].[EmployeeID], [t0].[OrderDate], [
t0].[RequiredDate], [t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[Sh
ipName], [t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion], [t0].[ShipPosta
lCode], [t0].[ShipCountry]
FROM [dbo].[Orders] AS [t0]
WHERE [t0].[OrderID] = @p0

输出的SQL看来还比较正常。下面我们再来改一下我们的程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

 foreach (var t in result)
            {
                Console.WriteLine("OrderID:" + t.OrderID 
		+ "-OrderDate:" 
		+ t.OrderDate.Value.ToString("yyyy-MM-dd") 
		+"-CustomerName:"
		+ t.Customer.ContactName);
                foreach(var m in t.Order_Details)
                Console.WriteLine("ProductID:" 
		+ m.ProductID 
		+ "-Price:" 
		+ m.UnitPrice 
		+ "-Amount:" 
		+ m.Quantity);
            }

出了输出订单相关信息外，还输出其关联对象：客户姓名、订单中的产品编号、单价、数量

再来看看输出的SQL语句：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

SELECT [t0].[OrderID], [t0].[CustomerID], [t0].[EmployeeID], [t0].[OrderDate], [
t0].[RequiredDate], [t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[Sh
ipName], [t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion], [t0].[ShipPosta
lCode], [t0].[ShipCountry]
FROM [dbo].[Orders] AS [t0]
WHERE [t0].[OrderID] = @p0
 
 
SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactT
itle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Coun
try], [t0].[Phone], [t0].[Fax]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[CustomerID] = @p0
 
 
SELECT [t0].[OrderID], [t0].[ProductID], [t0].[UnitPrice], [t0].[Quantity], [t0]
.[Discount]
FROM [dbo].[Order Details] AS [t0]
WHERE [t0].[OrderID] = @p0

我们可以看到，对于我们修改后的代码，程序向数据库请求了三条SQL语句，当然，这还不是最坏的情况，但是我们在这里的确看到延迟加载似乎“变了味道”，不但没有节省开支，反而增大了网络浏览。怎样才能改善这样的情况呢？

关于立即加载

其实我们知道，有很多扩展方法会导致延迟加载失效，而开始立即执行。当我们在调用诸如：ToList、ToDictionary、ToLookup或者ToArray之类的扩展方法之后，程序会将最终的结果存放到某个临时的变量集合中，并让所有的数据一次性的加载完成。

另外，还有一种方式，通过设置DataContext的DeferredLoadingEnabled属性为false,显示的关闭默认的延迟加载方式。

1
2

LinqTestDataContext ctx = new LinqTestDataContext();
ctx.DeferredLoadingEnabled = false;

这些方式虽然比较方便，但是还是有一定的局限性。例如，简单的使用ToList只能解决一些简单的查询问题，而对于复杂的查询需求，ToList还是不能解决延迟取得子对象所引发的多次查询问题。并且，在大量数据被加载到内存中的时候，对内存的需求也是很大的。不过，幸好Linq to sql给我们提供了另外一套不错的方法。

使用DataLoadOptions实现对加载对象的优化

Linq to Sql提供DataLoadOptions，用以立即加载关联的对象数据，其中包含两种方法：

LoadWith方法，用于立即加载与主对象相关联的数据

AssociateWith方法，用于对关联对象的数据进行筛选，并加载

有了DataLoadOptions，我们就可以用如下的方式优化我们的查询中需要加载的对象：

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

            LinqTestDataContext ctx = new LinqTestDataContext();
            ctx.Log = Console.Out;
 
            DataLoadOptions dl = new DataLoadOptions();
            dl.LoadWith<order>(p => p.Customer);
            dl.LoadWith<order>(p => p.Order_Details);
            ctx.LoadOptions = dl;
 
            var result = ctx.Orders.Where(p => p.OrderID == 10251).ToList();
 
            foreach (var t in result)
            {
                Console.WriteLine("OrderID:" + 
		t.OrderID 
		+ "-OrderDate:" 
		+ t.OrderDate.Value.ToString("yyyy-MM-dd") 
		+"-CustomerName:"
		+ t.Customer.ContactName);
                foreach(var m in t.Order_Details)
                Console.WriteLine("ProductID:" 
		+ m.ProductID 
		+ "-Price:" 
		+ m.UnitPrice 
		+ "-Amount:" 
		+ m.Quantity);
            }

对于我们开发者而言，需要注意的是，对于同一个DataContext实例，DataLoadOptions只能设定一次，并且一旦设定，就无法更改。

接下来，运行程序，看看优化后，程序向数据库服务器请求的的SQL：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

SELECT [t0].[OrderID], [t0].[CustomerID], [t0].[EmployeeID], [t0].[OrderDate], [
t0].[RequiredDate], [t0].[ShippedDate], [t0].[ShipVia], [t0].[Freight], [t0].[Sh
ipName], [t0].[ShipAddress], [t0].[ShipCity], [t0].[ShipRegion], [t0].[ShipPosta
lCode], [t0].[ShipCountry], [t3].[OrderID] AS [OrderID2], [t3].[ProductID], [t3]
.[UnitPrice], [t3].[Quantity], [t3].[Discount], (
    SELECT COUNT(*)
    FROM [dbo].[Order Details] AS [t4]
    WHERE [t4].[OrderID] = [t0].[OrderID]
    ) AS [value], [t2].[test], [t2].[CustomerID] AS [CustomerID2], [t2].[Company
Name], [t2].[ContactName], [t2].[ContactTitle], [t2].[Address], [t2].[City], [t2
].[Region], [t2].[PostalCode], [t2].[Country], [t2].[Phone], [t2].[Fax]
FROM [dbo].[Orders] AS [t0]
LEFT OUTER JOIN (
    SELECT 1 AS [test], [t1].[CustomerID], [t1].[CompanyName], [t1].[ContactName
], [t1].[ContactTitle], [t1].[Address], [t1].[City], [t1].[Region], [t1].[Postal
Code], [t1].[Country], [t1].[Phone], [t1].[Fax]
    FROM [dbo].[Customers] AS [t1]
    ) AS [t2] ON [t2].[CustomerID] = [t0].[CustomerID]
LEFT OUTER JOIN [dbo].[Order Details] AS [t3] ON [t3].[OrderID] = [t0].[OrderID]
 
WHERE [t0].[OrderID] = @p0
ORDER BY [t0].[OrderID], [t2].[CustomerID], [t3].[ProductID]

可以看出，之前的分三次向数据库提交sql的情况，现在被程序优化为一条带LEFT JOIN的关联查询，而获取关联数据。三次SQL请求，被优化为一次，从而减少了数据库和网络流量开支，由此看来DataLoadOptions的好处不言而喻。

一点小结

延迟加载与立即加载，并无孰优孰劣之区别，在某些情况下，需要我们根据自己的需求和实际情况来选择来进行选择。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

回想一下，在小到普通的应用程序，大到企业级项目中，我们常常会遇到需要定时轮询和调度的场景，简单点的需求是每隔固定的秒数或者分钟、小时进行轮询，复杂点的是每周的某个时刻，或者每月，或者每年才执行一次，又或者更复杂的情景，某些天需要执行，某些天不执行。用Windows自带的计划任务，能够实现简单的逻辑，如果要用程序实现这样的逻辑，想必也很复杂了。其实，用Quartz能很好的应付这些情况。

Quartz.NET的核心模块分为几个部分，Scheduler、Job、JobDetail、Trigger

Scheduler:实现调度的主体，负责调度任务的开始、结束，Scheduler中包含已注册的JobDetail和Trigger,并且，当Trigger中的条件得以触发时，Scheduler负责执行和Trigger相关联的Job，实现任务的调度。
Job:需要被调度的任务，Job必须实现IJob接口的Execute方法，而Execute方法的内容，其实也就是我们需要根据不同的需求自己实现的业务逻辑。
JobDetail:包含对Job的具体描述，包括Job的名称、所属的Group名称、以及Job的Type描述，用以Quartz.NET通过反射实现对Job的调用。
Trigger:触发器，描述调度的触发条件和时机。

Quartz.NET之所以没把Job和Trigger设计在一起，而是采用一种松耦合的方式，把Job和Trigger独立为两个不同的对象，原因是因为在Quartz.NET中，Job和Trigger可以建立一种一对多的关系，也就是可以对一个调度任务绑定多个Trigger，另外的好处是当某个Job的Trigger过期的时候，可以直接为Job绑定新的Trigger而不用重新定义和这个Trigger相关联的Job。

最初见到Quartz.NET，还是0.6的版本，一直躺在偶的硬盘里面，直到最近项目中遇到很多需要定时轮询处理的情况，突然想到了Quartz.NET，打开它在sourceforge的大本营，才发现Quartz.NET已经更新到1.0.1版本了。

Quartz.NET为我们提供了简洁的API，通过简单的例子，我们就可以很快上手和使用

在Quartz.NET中，所有的Job都必须实现IJob接口：

1
2
3
4
5
6
7

namespace Quartz
{
    public interface IJob
    {
        void Execute(JobExecutionContext context);
    }
}

JobExecutionContext 包含运行时的一些上下文信息，还可以用来传递参数

编写我们自己的Job，实现IJob接口：

1
2
3
4
5
6
7
8
9
10
11
12

using Quartz;
 
namespace ExampleJob
{
    public class TestJob : IJob
    {
        public void Execute(JobExecutionContext context)
        {
            Console.WriteLine("Job executed!");
        }
    }
}

然后就可以通过Scheduler来调度任务了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 创建SchedulerFactory
ISchedulerFactory schedFact = new StdSchedulerFactory();
 
// 获取Scheduler实例
IScheduler sched = schedFact.GetScheduler();
sched.Start();
 
// 创建JobDetail
JobDetail jobDetail = new JobDetail("ExampleJob", "MyJobGroup", typeof(ExampleJob));
// 创建Trigger，每分钟触发一次
Trigger trigger = TriggerUtils.MakeMinutelyTrigger();
// 设定trigger的开始时间
trigger.StartTimeUtc = TriggerUtils.GetEvenHourDate(DateTime.UtcNow);
trigger.Name = "myTrigger";
sched.ScheduleJob(jobDetail, trigger);

这样，任务调度框架便会每分钟调度一次我们的Job，在控制台每分钟都能看到一句 ”Job executed!”，是不是很简单呢？

其实Quartz.NET还有很多方便开发人员的特性和高级功能，比如通过配置文件配置Job和Trigger，可以让你的调度程序更加灵活，以应对后续需求的变化，而不需要重新编译程序。另外，还有调度线程池、JobStore、Clustering等很多高级功能，等着我们去发现。

相关资源：

Quartz.NET 主页：http://quartznet.sourceforge.net

在sourceforge的Quartz.NET主页上，有入门教程供初学者查看：http://quartznet.sourceforge.net/tutorial/index.html

另外，博客园的张善友也把教程翻译成了中文的，供E文不好的同学学习和参考，地址：http://www.cnblogs.com/shanyou/archive/2007/08/25/QuartzNETtutorial.html

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

1.Foreach方法
首先上场的是Foreach，在使用Linq的时候，太容易派上用场了。比如，在使用Linq to Sql查询后，我们常常需要遍历结果，然后输出，代码如下：

1
2
3
4
5
6
7

DataClassDataContext ctx = new DataClassDataContext();
var result = ctx.Products.Where(p => p.ProductID >= 10);
 
foreach (var product in result)
{
    Console.WriteLine(product.ProductName);
}

自从有了Foreach，可以节省不少的力气了：

1
2

DataClassDataContext ctx = new DataClassDataContext();
ctx.Products.Where(p => p.ProductID >= 10).ForEach(p => Console.WriteLine(p.ProductName));

Foreach代码如下:

1
2
3
4
5
6
7

public static void ForEach (this IEnumerable source, Action action)
{
        foreach(var item in source)
        {
            action(item);
        }
}

2.In方法
判断某个类型的变量是否在一个序列中

1
2
3
4
5
6

string [] names = new string[] {"Andy", "Timothy", "Ben", "Rex", "Ven", "Ken"};
 
if(names.Contains("Timothy"))
{
    Console.WriteLine("Found!");
}

使用In方法:

1
2
3
4

if ("Timothy".In("Andy", "Timothy", "Ben", "Rex", "Ven", "Ken"))
{
    Console.WriteLine("Found!");
}

In方法代码如下:

1
2
3
4

public static bool (this T t, params T[] c)
{
    return c.Contains(t);
}

3.WinForm下的控件选择器(摘自 博客园-鹤冲天 的博客 http://www.cnblogs.com/ldp615/archive/2009/11/08/1598596.html)

1
2
3
4
5
6
7
8
9
10
11
12

public static IEnumerable GetControls(this Control control, Func filter) where T : Control
{
	foreach (Control c in control.Controls)
 	{
		if (c is T&&(filter == null||filter(c as T)))
		{
 			yield return c as T;
 		}
 		foreach (T _t in GetControls(c, filter))
 		yield return _t;
 	}
}

使用方法：

1
2

this.GetControls<button>(null).ForEach(b => b.Enabled = false);  //禁用界面上所有Button控件
</button>

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

而这些特性，都为LINQ的推出，构建好了基础。其中一个比较不错的特性，就是扩展方法。扩展方法，顾名思义，就是在类型定义完成之后，再继续为其添加新的方法。这是相当方便的，比如对于一个已经封装好的Assembly来说，我们不用改动Assembly的代码，而通过扩展方法就能实现对其功能的扩展，而且在调用的时候，仅仅通过代码，你几乎判断不出这是扩展方法，还是Assembly本身的方法。

扩展方法在.Net 3.5中的应用也是非常普遍的，如果你仔细观察，就会发现我们常用的Linq to Object中的Where,Select,Average,Sum等方法，以及Linq to SQL中的Where,Select,Average,Sum等方法，其实都是扩展方法，他们分别定义于System.Linq.Enumerable类和System.Linq.Queryable类之中。

就扩展方法本身而言，也存在一些限制之处。对于编译器来说，如果扩展方法和被扩展类型的方法发生冲突的时候，在调用此方法的时候，究竟是调用被扩展类型的方法，还是扩展方法呢？通过一个例子，我们就能发现其中的区别。

   1:    class Program

   2:      {

   3:          static void Main(string[] args)

   4:          {

   5:              new TestClassA().Display("Test");

   6:              new TestClassB().Display("Test");

   7:              Console.ReadLine();

   8:          }

   9:      }

  10:  

  11:      class TestClassA

  12:      {

  13:          public void Display(int b)

  14:          {

  15:              Console.WriteLine("This is TestClassA.Display() ...");

  16:          }

  17:      }

  18:  

  19:      class TestClassB

  20:      {

  21:          public void Display(string s)

  22:          {

  23:              Console.WriteLine("This is TestClassB.Display() ...");

  24:          }

  25:      }

  26:  

  27:      static class TestClassExtention

  28:      {

  29:          static public void Display(this object o, string s)

  30:          {

  31:              Console.WriteLine("This is TestClassExtention.Display() ...");

  32:          }

  33:      }

程序输出：

可以看出,TestClassA的方法和扩展方法并没有冲突，因为他们的方法签名是不一样的，而TestClassB的方法和扩展方法有冲突，因为他们的都是接受一个string类型的输入参数。从结果可以看到，程序对Display的方法调用，TestClassB本身的Display方法，要“优先”于扩展方法Display被调用。因此，类本身的方法如果满足调用条件，那么这个方法会被优先执行，只有在类当中无法找到同样参数的方法时，扩展方法才有机会被执行。所以，我们可以得出这样的结论：扩展方法的优先级较低，也即扩展方法不会覆盖同名的类本身的方法。

另外，还有一个比较明显的区别，就是扩展方法要远远弱于类本身的方法，比如，在一个类中，类的方法可以访问自己的非公有成员，而扩展方法做不到这一点。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

The page you are requesting cannot be served because of the extension configuration.
If the page is a script, add a handler. If the file should be downloaded, add a MIME map. 

这种错误应该是.svc文件没有映射到相关的handler上，因此IIS不知道怎么处理该请求。带着错误信息，在网上搜索了一把，终于找到了解决方法，看来搜索引擎很强大。

解决方法如下：

1.用管理员身份运行cmd命令行

2.切换到目录C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation

3.运行命令： servicemodelreg –i

这样，工具会自动把WCF相关的注册项安装到IIS7中，再打开浏览器访问WCF Service，一切正常。

细想了一下自己的装机过程，先装了VSTS和.net framework，后来发现IIS7没有在windows7里面默认安装，要到部署WCF的时候，才装好IIS7。这样在安装.net framework 3.0的时候，因为没有安装IIS7，所以一些注册项就没有起到作用。此方法可以将WCF的配置项重新配置到IIS7中，供同学们参考。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

* 可以创建基于图形用户界面的程序

* 可创建方法和类

* 可以调用所有的.NET Compact Framework的类。

* 执行文件操作

* 运行进程

* 使用.NET 2.0中的范型

* 支持C#的控制语句，包括循环、条件判断……

IDE的使用非常简单，写入你的代码，然后可以立即运行，看到结果。

简单的例子，如下：

   1:  using System.Windows.Forms;

   2:  namespace TestNS

   3:  {

   4:      class TestCL

   5:      {

   6:         public static void Main()

   7:         {

   8:              MessageBox.Show("Hello Timothy!");

   9:         }

  10:      }

  11:  }

点击菜单下面的Debug->Run,运行结果截图如下：

IDE自带一些简单的功能， 包括插入代码模板，编辑(复制、粘贴、剪切)功能，还支持插件功能。

软件下载地址： http://www.geocities.com/hrowson/wm5_software/cs_ide_mobile.zip

Code Sample: http://www.geocities.com/hrowson/wm5_software/cs_ide_mobile_samples.zip

用户手册、帮助文档地址： http://www.geocities.com/hrowson/wm5_software/cs_ide_mobile_manual/index.htm

作者主页：http://www.geocities.com/hrowson/wm5_software/index.htm

赶紧下载吧，write your C# code anywhere! 活活~~

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

容器的RegisterType函数包含多个支持泛型的重载，同时还包含了一一对应的非泛型重载。其中的重载函数，我们可以看到类似下面的声明：

   1:  RegisterType(LifetimeManager lifetime)

参数中的LifetimeManager类型，就是用来控制注册类型生命周期的。Unity中提供了几个继承自LifetimeManager的类作为注册类型的生命周期管理器。在目前的Unity 1.2版本中，共提供了3个LifetimeManager供我们直接在代码中调用。此外，我们也可以实现自己的LifetimeManager，不过必须实现LifetimeManager所必须的一些方法。

1.ContainerControlledLifetimeManager:

容器负责管理注册类型的生命周期，并且注册类型的生命周期和容器一致。当离开容器的作用域范围时，容器会被销毁，同时其中的注册类型也会被销毁。或者，当容器被显式销毁时，其中的注册类型也同样被销毁。但是在容器有效的作用域范围中，当我们使用Resolve方法，或者使用ResolveAll方法获取我们的注册类型的时候，容器会在第一次调用时，创建实例，但是在后面的调用中，我们始终只会得到相同的实例。我们可以利用这种Manager来实现Singleton模式。

2.ExternallyControlledLifetimeManager:

和上一种方式类似，不过容器在不会保留对注册类型的强引用，而只是保留弱引用。也就是说，如果这个注册类型没有在其他地方被强引用的时候，那么这个注册类型可能会被GC给干掉。

3.PerThreadLifetimeManager:

容器保证在每个线程中返回同一个对象实例，那么在不同的线程中，得到的实例是不同的。

下面我们可以试验一下不同的LifetimeManager的效果

a. 默认的情况，不显示的指明LifetimeManager

代码：

   1:  namespace UnityDemo

   2:  {

   3:      class Program

   4:      {

   5:          static void Main(string[] args)

   6:          {

   7:              IUnityContainer container = new UnityContainer();

   8:              container.RegisterType();

   9:  

  10:              INotify notify1 = container.Resolve();

  11:  

  12:              INotify notify2 = container.Resolve();

  13:  

  14:              Console.WriteLine("notify1:" + notify1.GetHashCode());

  15:              Console.WriteLine("notify2:" + notify2.GetHashCode());

  16:  

  17:              Console.ReadLine();

  18:          }

  19:      }

  20:  }

运行结果：

从结果我们可以看到，默认情况下不指定LifetimeManager的时候，每次我们获得的Instance其实不是同一个Instance.

b.使用ContainerControlledLifetimeManager

代码：

   1:  namespace UnityDemo

   2:  {

   3:      class Program

   4:      {

   5:          static void Main(string[] args)

   6:          {

   7:              IUnityContainer container = new UnityContainer();

   8:              container.RegisterType(new ContainerControlledLifetimeManager());

   9:  

  10:              INotify notify1 = container.Resolve();

  11:  

  12:              INotify notify2 = container.Resolve();

  13:  

  14:              Console.WriteLine("notify1:" + notify1.GetHashCode());

  15:              Console.WriteLine("notify2:" + notify2.GetHashCode());

  16:  

  17:              Console.ReadLine();

  18:          }

  19:      }

  20:  }

运行结果:

使用ContainerControlledLifetimeManager，在Container生命中期内，我们得到的Instance是同一个。

c.使用PerThreadLifetimeManager

代码：

   1:  namespace UnityDemo

   2:  {

   3:      class Program

   4:      {

   5:          static void Main(string[] args)

   6:          {

   7:              IUnityContainer container = new UnityContainer();

   8:              container.RegisterType(new PerThreadLifetimeManager());

   9:  

  10:              Thread thread1 = new Thread(new ParameterizedThreadStart(ThreadProc1));

  11:              Thread thread2 = new Thread(new ParameterizedThreadStart(ThreadProc2));

  12:  

  13:              thread1.Start(container);

  14:              thread2.Start(container);

  15:  

  16:              Console.ReadLine();

  17:          }

  18:  

  19:          static void ThreadProc1(object obj)

  20:          {

  21:              INotify notify1 = (obj as IUnityContainer).Resolve();

  22:              INotify notify2 = (obj as IUnityContainer).Resolve();

  23:  

  24:              Console.WriteLine("ThreadProc1 --- notify1:" + notify1.GetHashCode());

  25:              Console.WriteLine("ThreadProc1 --- notify2:" + notify2.GetHashCode());

  26:  

  27:          }

  28:  

  29:          static void ThreadProc2(object obj)

  30:          {

  31:              INotify notify1 = (obj as IUnityContainer).Resolve();

  32:              INotify notify2 = (obj as IUnityContainer).Resolve();

  33:  

  34:              Console.WriteLine("ThreadProc2 --- notify1:" + notify1.GetHashCode());

  35:              Console.WriteLine("ThreadProc2 --- notify2:" + notify2.GetHashCode());

  36:          }

  37:      }

  38:  }

运行结果：

 在结果中可以看到，同一个线程中连续两次获取到的是同一个Instance，而不同的线程中获取到的Instance不一样。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

   1:  using System.Configuration;

   2:  using Microsoft.Practices.Unity.Configuration;

此外，需要修改应用程序的配置文件：

在configSections节点中，加入Unity的section配置信息

...


type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

<configSections>
...


type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

其中name是section的名称，type就是处理该section的程序类型，Unity提供了UnityConfigurationSection，负责处理配置文件信息，它包含在程序集Microsoft.Practices.Unity.Configuration中

接下来，需要在configuration节点中增加Unity配置节点，格式如下：

   1:  

   2:      

   3:        "" type="" />

   4:      

   5:      

   6:        

   7:           

   8:             "" mapTo="" />

   9:           

  10:           

  11:             "" type="" value="" />

  12:           

  13:        

  14:      

  16:  

unity的子元素，包含节点大致如上，其宗typeAliases是type别名，能够简化下面types中type的配置。containers节点中可以包含多个container的配置。container主要包含的子元素有types元素，instance元素，types元素可以包含多个type元素，用以添加注册类型，instance主要用来添加实例到容器中。type元素，主要包含四个属性：

name：表示注册类型的名称，此属性在配置中可选。

type:注册的源类型

mapto:注册的目标类型

lifetime:设置注册类型的生命周期

此外，还有instances元素，包括name,type,value,typeConverter四个属性。value表示注册实例的初始值，typeConverter是用以转换提供的值到实例的匹配类型的类型转换器。

具体的元素含义，可以参考Unity的帮助文档。

下面我们还是采用Monitor的例子，来实现用配置文件注册类型，配置文件示例：

   1:  "1.0" encoding="utf-8" ?>

   2:  

   3:    

   4:  
"unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />

   5:    

   6:  

   7:    

   8:      

   9:        

  10:          

  11:            "UnityDemo.IMonitor,UnityDemo" mapTo="UnityDemo.Monitor,UnityDemo" />

  12:            "UnityDemo.INotify,UnityDemo" mapTo="UnityDemo.EmailNotify,UnityDemo" />

  13:          

  14:        

  15:      

  16:    

  17:  

  18:  

程序代码修改如下：

   1:  using System;

   2:  

   3:  using Microsoft.Practices.Unity;

   4:  using Microsoft.Practices.Unity.Configuration;

   5:  using System.Configuration;

   6:  

   7:  namespace UnityDemo

   8:  {

   9:      class Program

  10:      {

  11:          static void Main(string[] args)

  12:          {

  13:              IUnityContainer container = new UnityContainer();

  14:              UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

  15:              section.Containers.Default.Configure(container);

  16:  

  17:              IMonitor monitor = container.Resolve();

  18:              monitor.Alarm();

  19:  

  20:              Console.ReadLine();

  21:          }

  22:      }

  23:  }

编译运行结果：

使用配置文件，还有许多方便的地方，比如对于程序的扩展而言，新增的模块不再需要修改已编译好的程序，而只需要修改配置文件就可以方便的实现新模块的注册，对于系统的稳定性和可维护性都非常有好处。

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

在平常的软件编码过程中，程序的逻辑往往很复杂，尤其是大型项目的开发中，一个模块常常会去引用其他的模块，假设我们有一个监控器类，用来监控CPU的温度，当温度达到预警的范围时，监控器有一个报警的方法，方法里面通过短信提醒器，以发送短信的方式通知维护人员。于是就出现了下面这样一段最为常见的代码：

   1:  public class Monitor

   2:  {

   3:         public void Alarm()

   4:         {

   5:                 SMSNotify notify = new SMSNotify();

   6:                 notify.Send();

   7:          }

   8:  }

在Monitor类中，直接引用到了一个短信提醒器的类，这是最为不灵活和最不易于扩展的一种方式。或许我们想到了面向接口编程，利用多态的好处，可以提供灵活的不同子类的实现，增加代码扩展性等等。但是说到底，接口一定是需要实现的，也就是如下语句迟早要执行：

   1:  public void Alarm()

   2:  {

   3:         INotify notify = new SMSNotify();

   4:         notify.Send();

   5:  }

这样看来，在实现INotify这个接口的时候，仍然需要具体的类来实现，而这样的代码在程序编译的时候就已经固定下来，如果以后需要使用新的提醒器，仍旧需要修改源代码并重新编译。并且在我们的Monitor类中，明显依赖SMSNotify类，二者之间的耦合度非常紧密。因此Ioc(控制反转)模式被提出用来解决这种问题，也即把接口的具体实现延缓到运行时，接口的实现类是在运行时被装载的。这样，就算有了新的实现类，也不需要更改调用者的代码(可以在Unity中使用配置文件的方式实现)。这种Ioc模式可以被形象的比喻为：接口就像一个空壳，而在具体实现时，向这个空壳注入内容，而让它成为一个真正的实体。这种模式也被形象的称为：依赖注入。通过使用Unity，我们能构建松耦合的软件，并且对象之间相互关联的细节，我们也不必关心，可以交由依赖注入容器全权负责。

前面也提到了依赖注入常用的三种形式：构造器注入、属性注入和方法调用注入，我们可以通过例子来实现这三种形式的注入。还是以上面的场景为例，我们的几个类和接口如下图：

1.Constructor Injection

IMonitor接口定义：

   1:  public interface IMonitor

   2:  {

   3:      void Alarm();

   4:  }

Monitor类：

   1:  public class Monitor : IMonitor

   2:  {

   3:      private INotify notify;

   4:  

   5:      public Monitor(INotify n)

   6:      {

   7:          notify = n;

   8:      }

   9:  

  10:      public void Alarm()

  11:      {

  12:          notify.Send();

  13:      }

  14:  }

INotify接口定义：

   1:  public interface INotify

   2:  {

   3:      void Send();

   4:  }

EmailNotify类：

   1:  public class EmailNotify : INotify

   2:  {

   3:      public void Send()

   4:      {

   5:          Console.WriteLine("Send Email Notify...");

   6:      }

   7:  }

SMSNotify类：

   1:  public class SMSNotify : INotify

   2:  {

   3:      public void Send()

   4:      {

   5:          Console.WriteLine("Send SMS Notify...");

   6:      }

   7:  }

可以看到，在Monitor类的构造函数里面，传入的参数是一个INotify接口类型，Alarm方法，调用了实现类的Send方法，但具体调用哪一个实现类的Send方法，只有在注入实体后才知道。Unity容器中，通常使用RegisterType和Resolve方法来分别注册和获取实例，并且这两个方法有很多泛型和非泛型的重载，具体的类型和参数，可以参考Unity的官方帮助文档。

现在我们向Monitor的构造函数注入实现INotify接口的实例:

   1:  static void Main(string[] args)

   2:  {

   3:      IUnityContainer container = new UnityContainer();

   4:      container.RegisterType<IMonitor, Monitor>().RegisterType<INotify, SMSNotify>();

   5:  

   6:      IMonitor monitor = container.Resolve<IMonitor>();

   7:      monitor.Alarm();

   8:  

   9:      Console.ReadLine();

  10:  }

代码中我们注入的INotify实例是SMSNotify类的实例，然后调用monitor.Alrarm()，里面会调用notify.Send().
运行查看结果：

上面是针对单个构造函数的情况，如果有多个构造函数，需要指明哪个构造函数是需要被注入的,也即需要在指定被注入的构造函数加上attribute:InjectionConstructor

   1:  public Monitor(INotify n, string name)

   2:  {

   3:      notify = n;

   4:  }

   5:  

   6:  [InjectionConstructor]

   7:  public Monitor(INotify n)

   8:  {

   9:      notify = n;

  10:  }

运行后可得到一样的结果.

2.Property Injection

通过属性注入，我们需要加上attribute: Dependency，使得Unity容器在获取类对象实例时，自动实例化该属性所依赖的对象，并注入到属性中。

修改Monitor类,实现下面的代码：

   1:  public class Monitor : IMonitor

   2:  {

   3:      [Dependency]

   4:      public INotify Notify { get; set; }

   5:  

   6:      public void Alarm()

   7:      {

   8:          Notify.Send();

   9:      }

  10:  }

再在Main函数里面，修改原有的代码，这次我们让容器注入EmailNotify实例：

   1:  container.RegisterType<INotify, EmailNotify>();

运行查看结果：
还有一个比较方便的地方，可以为Dependency特性指定名称，这样，在注入时，会将RegisterType所指定的对应名称的实体进行注入，例如：

   1:      public class Monitor : IMonitor

   2:      {

   3:          [Dependency("SMS")]

   4:          public INotify Notify { get; set; }

   5:  

   6:          public void Alarm()

   7:          {

   8:              Notify.Send();

   9:          }

  10:      }

修改Main函数，在RegisterType函数中指定注入名称:

   1:              container.RegisterType<INotify, EmailNotify>("Email");

   2:              container.RegisterType<INotify, SMSNotify>("SMS");

运行查看结果：

3.Method Call Injection

Method Call Injection注入的时机和Constructor Injection有一定的区别，构造函数注入，是在容器创建实例的时候，而方法调用注入，是在方法被调用的时候。实现方法调用注入，需要在指定注入的方法前加上attribute: InjectionMethod

修改Monitor类的代码如下：

   1:      public class Monitor : IMonitor

   2:      {

   3:          private INotify notify;

   4:  

   5:          [InjectionMethod]

   6:          public void GetNotify(INotify n)

   7:          {

   8:              notify = n;

   9:          }

  10:  

  11:          public void Alarm()

  12:          {

  13:              notify.Send();

  14:          }

  15:      }

在程序运行时，容器会自动实例化GetNotify方法所依赖的对象，并自动调用该方法，将其注入到方法中。

Main函数如下：

   1:          static void Main(string[] args)

   2:          {

   3:              IUnityContainer container = new UnityContainer();

   4:              container.RegisterType<IMonitor, Monitor>();

   5:              container.RegisterType<INotify, EmailNotify>();

   6:  

   7:              IMonitor monitor = container.Resolve<IMonitor>();

   8:              monitor.Alarm();

   9:  

  10:              Console.ReadLine();

  11:          }

运行查看结果：

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!

利用SQL脚本内置的几个函数，我们能灵活的对日期进行计算和比较。常用的几个函数：GETDATE(),DATEDIFF(),DATEADD()

GETDATE() 当然顾名思义，得到当前的日期，返回类型是DateTime类型。

DATEDIFF ( datepart , startdate , enddate ) 用于判断在两个日期之间存在的指定时间间隔的数目。

第一个参数是指定时间间隔的类型,例如mm(月),dd(天)，yy(年),ms(毫秒）,ss(秒），不同的间隔类型，返回的结果也不一样。

DATEADD (datepart , number, date ) 用于日期运算的函数，将传入的日期，加上指定时间间隔数目的日期。

例如，计算得到本年的第一天：

Select DATEADD(yy, DATEDIFF(yy,0,getdate()), 0)

我们来分析下这个SQL语句就可以知道，首先从最里面的getdate()开始，getdate()得到当前日期和时间，外层的datediff，计算当前日期和1900-01-01 00:00:00之间的时间间隔，返回单位是以年来统计的，如果我们分开看DATEDIFF(yy,0,getdate()),0)的结果，返回就是:109。返回的109，传递给最外层的DATEADD函数，将1900-01-01 00：00：00加上109年，得到的结果，自然就是2009-01-01 00:00:00了，也即本年的第一天。

同样，灵活的利用这几个函数的组合，我们可以得到不同的结果：

得到当月的第一天：Select DATEADD(mm, DATEDIFF(mm,0,getdate()), 0)

得到当前季度的第一天：Select DATEADD(qq, DATEDIFF(qq,0,getdate()), 0)

得到当天的起始时间： Select DATEADD(dd, DATEDIFF(dd,0,getdate()), 0)

得到上个月最后一天： Select DATEADD(ms,-3,DATEADD(mm, DATEDIFF(mm,0,getdate()), 0))

得到上个月的第一天： Select DATEADD(m,-1,DATEADD(mm, DATEDIFF(mm,0,getdate()), 0))

其原理就是得到当月第一天，再减去三毫秒(SQL的时间以3毫秒为一个单位)，这样以当前为2月，得到的结果就是：2009-01-31 23:59:59.997

得到去年的最后一天： Select DATEADD(ms,-3,DATEADD(yy, DATEDIFF(yy,0,getdate()), 0))

得到本月的最后一天： Select DATEADD(ms,-3,DATEADD(mm, DATEDIFF(m,0,getdate())+1, 0))

得到本年的最后一天： Select DATEADD(ms,-3,DATEADD(yy, DATEDIFF(yy,0,getdate())+1, 0))

得到本月的第一个星期一： Select DATEADD(wk, DATEDIFF(wk,0,DATEADD(dd,6-datepart(day,getdate()),getdate())), 0)

声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论，对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权，除非注明，本站文章均为原创，转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!