简单的.NET后台定时服务框架

  后台服务只要是有一定经验的开发人员都接触过,其中离不开服务创建,调度逻辑处理,业务逻辑编写等环节。往往我们在新建一个后台服务项目的时候都会去拷贝以前的代码,再写一些线程等方式去完成,然后又去处理服务的安装问题。大部分时间都是浪费在这些重复的工作上。
  这里提供的是一个简单的后台服务处理框架,简单的后台服务处理框支持(按指定间隔时间执行;每天指定时间执行每天一次;指定时间执行一次;每天指定开始和结束时间并且按照指定间隔时间执行),开发新的定时服务任务时,只需要实现抽象类的方法、添加任务配置以及运行安装脚本即可完成一个服务的开发。

  框架代码路径:框架代码

框架支持配置执行类型来控制任务的执行逻辑
     按指定间隔时间执行
     每天指定时间执行 每天一次
     指定时间执行一次
     每天指定开始和结束时间并且按照指定间隔时间执行

  

  

  以下是一个定时执行存储过程的任务。

  继承基类并编写业务逻辑代码

  

using DataAccessHelper.SQLHelper;
using Services.Common;
using System;

namespace Services.Tasks
{
    public class CallProcTask : ServiceBase
    {
        protected override void Exec()
        {
            try
            {
                if (_isStart)
                {
                    if (!string.IsNullOrWhiteSpace(Config.Param))
                    {
                        LogFactory.GetLogger().Info(string.Format("开始执行存储过程 {0}", Config.Param));
                        SQLHelperFactory.Instance.ExecuteNonQuery(Config.Param, null);
                        LogFactory.GetLogger().Info(string.Format("执行存储过程 {0} 完成", Config.Param));
                    }
                }
            }
            catch (Exception ex)
            {
                LogFactory.GetLogger().Error(string.Format("执行存储过程 {0} 异常:{1}", Config.Param, ex));
            }
        }
    }
}

  配置服务名称

  

  配置每次执行间隔60秒

 [
  { //循环执行任务 每次执行间隔60秒
    "ServiceName": "CallProcTask-proc_test任务",//服务名称 非空
    "Assembly": "Services.exe",//程序集 非空
    "Methods": "Services.Tasks.CallProcTask",//执行类名  对应业务的类名 非空
    "S_Interval": 60,//间隔时间 单位秒
    "ExecType": 0,//执行类型 ( 0:按指定间隔时间执行 1:每天指定时间执行 每天一次 2:指定时间执行一次 3.每天指定开始和结束时间并且按照指定间隔时间执行) 可空默认0
    "Param": "proc_test"//自定义参数 在本案例中为SQL参数 可空
  }
]

  编写完成后,编译,运行:Install.bat 即可在服务管理器中看到对应的服务。

  框架代码路径:框架代码

时间: 2024-10-26 14:55:57

简单的.NET后台定时服务框架的相关文章

使用框架的php如果使用定时服务Cronjob

工作需要用php开发了个监控的小程序,既然是监控就需要定时执行. 之前我用的是chrome加个定时刷新的小插件,放在服务器上运行,也能实现,就是别扭. 通用正规的做法应该是:linux上的Cron和windows上的计划任务.使用php.exe执行脚本,win中还要多写个bat文件,很多文章中有提及. 个人不习惯用ignore_user_abort(true) 但存在一个问题,就是执行的php文件只能是简单的脚本,不能使用框架,因为框架的相对目录路径导致运行出错.既然是监控程序,肯定要用到数据库

JointCode.Shuttle,一个简单高效的跨 AppDomain 通信的服务框架

JointCode.Shuttle 是一个用于 AppDomain 间通信的服务架构. 1. 什么情况下使用 JointCode.Shuttle 在 .net / mono 开发中,一般不太需要使用额外的 AppDomain,但在一些 特定情况下,让代码运行在新的 AppDomain 中也许是一个好的选择. 当代码需要跨越 AppDomain 边界访问另一个 AppDomain 时,便产生了跨 AppDomain 通信的问题,JointCode.Shuttle 正是专为此目的而开发的一个服务框架

最为纯粹简单的后台管理页面框架

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title

OpenLayer3+PostGIS+GeoServer 搭建简单GIS服务框架问题探究

传统GIS开发中,我们一般会采用ArcGIS或者SuperMap作为GIS平台来进行开发,简单的分析查询会采用官方api或者leaflet,esri-leaflet等进行开发,复杂的查询分析统计功能会利用Geoprocessor(简称GP)来进行操作,采用这种商业平台好处显而易见是开发效率很大的提升,因为在这么多年的发展过程中,官方社区或者一些解决方案都很成熟.在开发过程中遇到的一般问题如果不是很好解决,也可以很方便的向技术支持寻求帮助.但是缺点就是费用很高,一整套产品下来就要好几十万,对于开发

MIUI目前为止最简单安装谷歌服务框架教程

安装谷歌服务框架方法有很多,比如用第三方rec卡刷gapps包.用第三方工具安装......然而这些对于新手来说还是比较难的! 我今天说的方法可以说是最简单的:1.不需要修改文件:2.不需要借助第三方软件:3.卸载方便,随时可以卸载4.适用于任何安卓版本的miui,不分稳定版开发版. 教程开始 很简单的,在小米应用商店搜索gamil(会提示没找到相关应用,这时我们点豌豆荚搜索)搜索到之后点安装,会提示是否安装谷歌服务,点确定后自动就装好了,就是这么简单...... <ignore_js_op>

简单Spring Cloud 微服务框架搭建

微服务是现在比较流行的技术,对于程序猿而言,了解并搭建一个基本的微服务框架是很有必要滴. 微服务包含的内容非常多,一般小伙伴们可以根据自己的需求不断添加各种组件.框架. 一般情况下,基本的微服务框架包含:框架:注册中心.负载均衡.声明式服务(feign).容错(hystrix).网关(权限)gateway 和 配置(resource) 注册中心:现在比较常用的有eureka.nacos 负载均衡:包括feign.ribbon等技术,相关对比可以参考另一位老哥的博客:<负载均衡之feign与rib

【干货】手动搭建一套可自动化构建的微服务框架

如何阅读 本文篇幅较长,我花了两天的时间完成,大约需要半小时阅读. 本文分为理论篇和实践篇,由于代码在手机端展示并不理想,建议大家收藏之后在PC端阅读.实践篇边动手边阅读更有助于理解. 在阅读的同时,也麻烦各位大佬多多分享! 本文你将学到什么? 本文将以原理+实战的方式,首先对"微服务"相关的概念进行知识点扫盲,然后开始手把手教你搭建这一整套的微服务系统. 这套微服务框架能干啥? 这套系统搭建完之后,那可就厉害了: 微服务架构你的整个应用程序将会被拆分成一个个功能独立的子系统,独立运行

Alibaba开源的分布式服务框架:Dubbo是what?

  Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合).从服务模型的角度来看,      Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.关于注册中心.协议支持.服务监控等内容,详见后面描述.  Webservice也是一种服务框架,但是webservice并不是分布式的服务框

分布式服务框架Dubbo

随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进. 单一应用架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本. 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键. 垂直应用架构  当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率. 此时,用于加速前端页面开发的 Web框架(MVC) 是关键. 分布式服