当学完第二课之后，你欣喜的发现，让jobs工作起来是还是相当简单的。虽然让jobs运行起来很简单，对于其执行的关键内容还是需要知道的。它们是IJob接口中的Execute和JobDetails。
当你定义一个实现IJob接口的类的时候，你需要在里面实现实际需要执行的代码。Quartz.NET需要知道关于这代码的各种信息，这样 Quartz.NET才能像你期望的那样工作。这些细节是在JobDetail类中进行了描述，在上一节以及进行了简单的描述。
JobDetail由JobBuilder进行实例化的。JobBuilder容许开发人员使用 fluent interface.进行自定义JobDetail细节。
让我们花点时间看Job的机制以及在Quartz.NET中的生命周期。在第一节中已经看到的例子让我们再看一遍：
1 // define the job and tie it to our HelloJob class
2 IJobDetail job = JobBuilder.Create<HelloJob>()
3 .WithIdentity("myJob", "group1")
4 .Build();
5
6 // Trigger the job to run now, and then every 40 seconds
7 ITrigger trigger = TriggerBuilder.Create()
8 .WithIdentity("myTrigger", "group1")
9 .StartNow()
10 .WithSimpleSchedule(x => x
11 .WithIntervalInSeconds(40)
12 .RepeatForever())
13 .Build();
14
15 sched.ScheduleJob(job, trigger);
现在定义一个HelloJob 如下所示：
1 public class HelloJob : IJob
2 {
3 public void Execute(IJobExecutionContext context)
4 {
5 Console.WriteLine("HelloJob is executing.");
6 }
7 }
请注意，在这里给scheduler 一个IJobDetail 实例，它只需要一个job实例就能进行运行。当scheduler执行job的时候，scheduler 会在调用Execute方法之前实例化一个job实例。 能实例化job的前提是job类中需要有个无参的构造函数。还有一个需要注意的是，在job类中定义任何数据字段其实没有什么太大的意义，因为在job的运行期间不会保留这些数据字段。
看到这你或许会问，那我如何为一个job提供属性和配置信息呢？并且这么能跟踪保持job的执行状态呢？要回答这些问题，关键要弄懂JobDataMap，它是JobDetail中的一部分。
JobDataMap
JobDataMap中可用于容纳任何数量的您希望提供给job实例在执行时（可序列化）的对象。JobDataMap实现了IDictionary接口，并为其添加了一些用于存储和检索基本类型的数据的实用方法。
下面是JobDataMap 快速上手代码，在添加job到scheduler之前先为JobDataMap添加一些数据 ：
1 // define the job and tie it to our DumbJob class 2 IJobDetail job = JobBuilder.Create<DumbJob>() 3 .WithIdentity("myJob", "group1") // name "myJob", group "group1" 4 .UsingJobData("jobSays", "Hello World!") 5 .UsingJobData("myFloatValue", 3.141f) 6 .Build();下面是从执行的job中获取JobDataMap 数据
1 Getting Values from a JobDataMap 2 public class DumbJob : IJob 3 { 4 public void Execute(JobExecutionContext context) 5 { 6 JobKey key = context.JobDetail.Key; 7 8 JobDataMap dataMap = context.JobDetail.JobDataMap; 9 10 string jobSays = dataMap.GetString("jobSays"); 11 float myFloatValue = dataMap.GetFloat("myFloatValue"); 12 13 Console.Error.WriteLine("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue); 14 } 15 }如果你准备使用一个持久的JobStore （JobStore 将在JobStore 部分进行讨论）你应该关注将在JobDataMap放些什么。因为它会被序列化，所以更容易产生版本问题。在标准的版本中是安全的，除此之外，任何人都可以改变你的实体类。所以不得不关心兼容性会被破坏的情况。
所以你可以把AdoJobStore and JobDataMap 放进map中，仅包含着原始函数与字符串数据，因此消除了序列化的各种问题。
由于Quartz默认JobFactory会再job实例化的时候去实例那些带有set属性的，所以当你添加带有set访问的属性的时候会在JobDataMap中创建对应的key将其保存。这样就不要进行显示区指示在execute方法方法中进行映射。
Trigger也有其相关的JobDataMap。当你需要多个Trigger进行调度和重复scheduler 这是非常有用的。每个Trigger是独立的，并且需要你单独输入配置信息。
JobDataMap 将JobExecutionContext 作为job执行时候的上下文。它里面包含了JobDataMap 和Trigger并且覆盖前面相同的值。
下面是来自JobExecutionContext获取数据的作业执行过程中合并的JobDataMap的一个简单的例子：
1 public class DumbJob : IJob 2 { 3 public void Execute(IJobExecutionContext context) 4 { 5 JobKey key = context.JobDetail.Key; 6 7 JobDataMap dataMap = context.MergedJobDataMap; // Note the difference from the previous example 8 9 string jobSays = dataMap.GetString("jobSays"); 10 float myFloatValue = dataMap.GetFloat("myFloatValue"); 11 IList<DateTimeOffset> state = (IList<DateTimeOffset>) dataMap["myStateData"]; 12 state.Add(DateTimeOffset.UtcNow); 13 14 Console.Error.WriteLine("Instance " + key + " of DumbJob says: " + jobSays + ", and val is: " + myFloatValue); 15 } 16 }或者，如果你想依靠的JobFactory“注入”数据映射值到你的类，它可能看起来像这个：
1 public class DumbJob : IJob 2 { 3 public string JobSays { private get; set; } 4 public float FloatValue { private get; set; } 5 6 public void Execute(IJobExecutionContext context) 7 { 8 JobKey key = context.JobDetail.Key; 9 10 JobDataMap dataMap = context.MergedJobDataMap; // Note the difference from the previous example 11 12 IList<DateTimeOffset> state = (IList<DateTimeOffset>) dataMap["myStateData"]; 13 state.Add(DateTimeOffset.UtcNow); 14 15 Console.Error.WriteLine("Instance " + key + " of DumbJob says: " + JobSays + ", and val is: " + FloatValue); 16 } 17 }你会注意到类的整个代码较长，但在execute（）方法的代码是干净。人们还可以争辩说，虽然代码越长，它实际上花了更少的编码，如果程序员的IDE用于自动生成的属性，而不必手工编写单独的调用从JobDataMap中检索值。这是你的选择。
Job “Instances”
很多用户花费时间是困惑究竟是什么构成了“Job实例”。我们会尽力讲清楚这里，下面有关的工作状态和并发性的部分。
您可以创建一个job类，并通过创建JobDetails的多个实例的调度中存储了很多“实例定义” - 每一个都有自己的属性和JobDataMap - 并且他们都增加到scheduler中
例如，你可以创建一个实现所谓的“SalesReportJob”的IJob接口的类。这个job可能会被编码到期望发送给它（通过JobDataMap中）来指定销售报告应根据销售人员的姓名参数。然后它们可以创建多个定义的job（JobDetails），如“SalesReportForJoe”和“SalesReportForMike”具有“乔joe”和“Mike”在相应JobDataMaps作为输入到各自的job指定。
当Trigger启动，将一个JobDetail（实例定义），它会被自动加载，和job类是指通过对调度配置的JobFactory实例化。默认的JobFactory只是调用使用Activator.CreateInstance 调用job类的默认构造函数，然后尝试在匹配的JobDataMap中的键名该类调用setter属性。您可能希望创建自己的实现的JobFactory来完成的事情，如让你的应用程序的IoC或者DI容器产生/初始化作业实例。
In “Quartz speak”， 我们指的是每个存储的JobDetail作为“job定义”或“的JobDetail实例”，我们指的是每一个执行job作为“job实例”或“job定义实例”。通常，如果我们只是用这个词的“job”，我们指的是一个名为定义或JobDetail等。当我们指的是类实现job接口，我们平时使用的术语“job type”。
Job State and Concurrency
现在有一些关于Job的状态数据（aka JobDataMap）和并发性附加说明。可以天剑组合特性到你的job类上，来影响Quartz’的行为。
DisallowConcurrentExecution添加到Job类，告诉Quartz不执行给定的job定义的多个实例（即是指给定的job类）并发的属性。注意这里面的所说，必须小心使用。在上一节的例子中，如果“SalesReportJob”有这个属性，比只有一个“SalesReportForJoe”的实例可以在给定时间执行的，但它可以与“SalesReportForMike”的一个实例，同时执行。约束是基于一个实例定义（JobDetail等），而不是在工作类的实例。但是，它（quartz的设计），决定对类本身携带的属性，因为它决定对类进行怎样进行编译。
PersistJobDataAfterExecution是可以被添加到Job类，告诉quartz更新JobDetail的JobDataMap存储的副本属性在execute（）方法成功完成后（未抛出异常），使得同样的job在下一次执行（JobDetail）接收，而不是原先存储的值的更新的值。像DisallowConcurrentExecution属性，这适用于作业定义实例，而不是一个作业类的实例，虽然当时决定让job类携带的属性，因为它往往使对类是如何编码的差异（如‘有状态‘将需要显式地“理解”的执行方法中的代码）。
如果使用PersistJobDataAfterExecution属性，你应该认真考虑也使用DisallowConcurrentExecution属性，以避免留下什么数据时，同样的job（JobDetail）的两个实例并发执行存储可能的混淆（竞争条件）
Other Attributes Of Jobs
下面是可用于通过JobDetail等对象的job实例来定义的其他属性的简单总结：
持久性 - 如果job是不可持久的，它会自动从调度中删除，一旦不再有与之相关的任何活动的触发器。换句话说，非持久job具有一个寿命由其触发的存在的限制。
可恢复性 - 如果作业“要求恢复”，它是在调度的“硬关闭”的时间执行（即它崩溃中运行的过程中，或在机器关闭），然后重新执行当调度程序重新开始。在这种情况下，JobExecutionContext.Recovering属性将返回真。
JobExecutionException
最后，我们需要告诉你的IJob.Execute（..）方法的一些细节。你应该从执行方法抛出的唯一类型是JobExecutionException。正因为如此，你通常应该换execute方法的全部内容以‘的try-catch“块。你也应该花一些时间看的JobExecutionException的文档，你的工作可以用它来提供调度各种指令为你想怎么异常进行处理。