AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

Asp.net 面向接口可扩展框架之数据处理模块及EntityFramework扩展和Dapper扩展(含干货)

2018-11-14 1207
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 原文:Asp.net 面向接口可扩展框架之数据处理模块及EntityFramework扩展和Dapper扩展(含干货)接口数据处理模块是什么意思呢？实际上很简单,就是使用面向接口的思想和方式来做数据处理。
原文: Asp.net 面向接口可扩展框架之数据处理模块及EntityFramework扩展和Dapper扩展(含干货)

接口数据处理模块是什么意思呢？实际上很简单,就是使用面向接口的思想和方式来做数据处理。

还提到EntityFramework和Dapper,EntityFramework和Dapper是.net环境下推崇最高的两种ORM工具。

1、EntityFramework是出自微软根正苗红的.net下的ORM工具,直接在Vs工具和Mvc框架中集成了,默认生成的项目就是使用EntityFramework的;微软也一直都在维护更新升级,最新版本都到EF7了。也迁移到了最新的.net Core平台了。

2、Dapper也是个厉害的角色。号称.net下"无敌",速度最快

但是他们两个开发方式完全不一样,个人认为EntityFramework是基于领域模型的,Dapper是基于sql的

注:我以前没用Dapper做过项目。之前一直讨厌Dapper,对赤裸裸的sql有很大成见,原因一程序员去直接写sql搞不好就会导致sql注入风险,原因二我认为程序员应该花精力琢磨逻辑如何写,而不是和DBA比写sql的功底

注:EntityFramework我也用的少,我主导的项目都是用我自己开发的ORM工具,维护别人的项目经常碰到EntityFramework生成复杂到不可理喻的sql,而且EntityFramework几乎不能在一个项目中分库分表读写分离操作(这个问题已经解决，后面会讲到)

现在要做的就是让ORM工具(含EntityFramework和Dapper)以面向接口的方式工作,"屏蔽"掉一些个性化的差异

一、面向接口数据处理模块

面向接口数据处理模块很简单,就是一堆数据处理的接口,像数据仓储接口。有了它们几乎所有数据仓储都不用再定义新接口了,主要的核心接口全部公布如下:

    /// <summary>
    /// 实体泛型主键接口
    /// </summary>
    /// <typeparam name="TPrimaryKey"></typeparam>
    public interface IEntity<TPrimaryKey> : IEntity
    {
        /// <summary>
        /// 主键
        /// </summary>
        TPrimaryKey Id { get; set; }
    }
    /// <summary>
    /// 实体接口
    /// </summary>
    public interface IEntity
    {
        /// <summary>
        /// 主键
        /// </summary>
        object ObjId { get; }
    }
1、IEntity

注:主键是泛型(TPrimaryKey),意味着支持任意类型的主键,而不是简单粗暴的只支持int或者guid,当然也就支持复合主键了

    /// <summary>
    /// 泛型添加
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IEntityAdd<in TEntity>
    {
        /// <summary>
        /// 添加
        /// </summary>
        /// <param name="obj"></param>
        /// <returns></returns>
        object Add(TEntity obj);
    }
2、IEntityAdd 
    /// <summary>
    /// 泛型删除
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IEntityDel<in TEntity>
    {
        /// <summary>
        /// 删除
        /// </summary>
        /// <param name="obj"></param>
        /// <returns></returns>
        bool Del(TEntity obj);
    }
}
3、IEntityDel 
    /// <summary>
    /// 按主键删除
    /// </summary>
    /// <typeparam name="TPrimaryKey"></typeparam>
    public interface IEntityKeyDel<TPrimaryKey>
    {
        /// <summary>
        /// 按主键删除
        /// </summary>
        /// <param name="key"></param>
        /// <returns></returns>
        bool Del(TPrimaryKey key);
    }
4、IEntityKeyDel 
    /// <summary>
    /// 泛型修改
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IEntityUpdate<in TEntity>
    {
        /// <summary>
        /// 修改
        /// </summary>
        /// <param name="obj"></param>
        /// <returns></returns>
        bool Update(TEntity obj);
    }
5、IEntityUpdate 
    /// <summary>
    /// 泛型获取列表数据
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IEntityList<TEntity>
    {
        /// <summary>
        /// 获取所有数据
        /// </summary>
        /// <returns></returns>
        IEnumerable<TEntity> ListAll();
    }
6、IEntityList 
    /// <summary>
    /// 获取数据条数
    /// </summary>
    public interface ICount
    {
        /// <summary>
        /// 获取数据条数
        /// </summary>
        /// <returns></returns>
        int Count();
    }
7、ICount 
    /// <summary>
    /// 泛型查看
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IEntityView<TEntity>
    {
        /// <summary>
        /// 查看
        /// </summary>
        /// <param name="obj"></param>
        /// <returns></returns>
        TEntity View(TEntity obj);
    }
8、IEntityView 
    /// <summary>
    /// 泛型查主键看
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    /// <typeparam name="TPrimaryKey"></typeparam>
    public interface IEntityKeyView<TEntity, TPrimaryKey>
        where TEntity : IEntity<TPrimaryKey>
    {
        /// <summary>
        /// 按主键获取
        /// </summary>
        /// <param name="key"></param>
        /// <returns></returns>
        TEntity View(TPrimaryKey key);
    }
9、IEntityKeyView 
    /// <summary>
    /// 数据操作仓储接口
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    /// <typeparam name="TPrimaryKey"></typeparam>
    public interface IRepository<TEntity, TPrimaryKey> : IEntityAdd<TEntity>, IEntityUpdate<TEntity>, IEntityDel<TEntity>, IEntityKeyDel<TPrimaryKey>
        , IEntityView<TEntity>, IEntityKeyView<TEntity, TPrimaryKey>
        , IEntityList<TEntity>, ICount
        where TEntity : IEntity<TPrimaryKey>
    {
    }
10、IRepository 
    /// <summary>
    /// 按条件获取列表
    /// </summary>
    /// <typeparam name="TCondition"></typeparam>
    /// <typeparam name="T"></typeparam>
    public interface IEntityConditionList<T, in TCondition>
    {
        /// <summary>
        /// 按条件获取列表
        /// </summary>
        /// <param name="condition"></param>
        /// <returns></returns>
        IEnumerable<T> List(TCondition condition);
    }
11、IEntityConditionList 
    /// <summary>
    /// 按条件获取计数(统计)
    /// </summary>
    /// <typeparam name="TCondition"></typeparam>
    public interface IEntityConditionCount<in TCondition>
    {
        /// <summary>
        /// 按条件获取计数(统计)
        /// </summary>
        /// <param name="condition"></param>
        /// <returns></returns>
        int Count(TCondition condition);
    }
12、IEntityConditionCount 
    /// <summary>
    /// 按条件修改接口
    /// </summary>
    /// <typeparam name="TCondition"></typeparam>
    /// <typeparam name="TUpdateContract"></typeparam>
    public interface IEntityConditionUpdate<in TCondition, in TUpdateContract>
    {
        /// <summary>
        /// 按条件修改
        /// </summary>
        /// <param name="condition"></param>
        /// <param name="contract"></param>
        /// <returns></returns>
        bool Update(TCondition condition, TUpdateContract contract);
    }
13、IEntityConditionUpdate 
    /// <summary>
    /// 按条件删除接口
    /// </summary>
    /// <typeparam name="TCondition"></typeparam>
    public interface IEntityConditionDel<in TCondition> 
    {
        /// <summary>
        /// 按条件删除
        /// </summary>
        /// <param name="condition"></param>
        /// <returns></returns>
        bool Del(TCondition condition);
    }
14、IEntityConditionDel

以上14个大接口涵盖了数据处理中的添、删、改、查各种情况(当然可能不全面还会增加),虽然都是虚的,当绝对是满满的干货(这14个接口是我好几年逐步的总结)。

接口有什么作用,接口就是规则就是标准就是契约

其一、基于接口开发出来的功能模块可高度复用。

其二、依赖接口开发的项目低耦合,可以各自分工同时多线程并行进行

其三、调用接口的模块可以方便的更换部分接口的实现,不会导致大范围的连锁反应,相当于可以给飞行中飞机换引擎

这里要强调的是以上接口不只是操作数据库,数据库只是数据的一种形式,还可以是文件、远程服务、Redis、nosql等。

以上都是"虚"的,来的实际例子使用这些接口

 

二、首先看一个Dapper(封装后的)开发Mvc例子

1、Model

    /// <summary>
    /// 文章
    /// </summary>
    public class Article : IEntity<int>
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public int BodyId { get; set; }
        public int UserId { get; set; }

        #region IEntity<int>
        object IEntity.ObjId { get { return Id; } }
        #endregion
    }
Article

2、View

@model IEnumerable<CMS.Models.Article>

@{
    ViewBag.Title = "Index";
}

<h2>Index</h2>

<p>
    @Html.ActionLink("Create New", "Create")
</p>
<table>
    <tr>
        <th>
            @Html.DisplayNameFor(model => model.Title)
        </th>
        <th>
            @Html.DisplayNameFor(model => model.BodyId)
        </th>
        <th>
            @Html.DisplayNameFor(model => model.UserId)
        </th>
        <th></th>
    </tr>

@foreach (var item in Model) {
    <tr>
        <td>
            @Html.DisplayFor(modelItem => item.Title)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.BodyId)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.UserId)
        </td>
        <td>
            @Html.ActionLink("Edit", "Edit", new { id=item.Id }) |
            @Html.ActionLink("Details", "Details", new { id=item.Id }) |
            @Html.ActionLink("Delete", "Delete", new { id=item.Id })
        </td>
    </tr>
}

</table>
Index.cshtml

注:View是简单了一点,就是Vs默认生成的,只是为了演示功能,大家将就看一下吧

3、Controller

        #region DI配置
        [Dependency("IndexOperater")]
        public IEntityList<CMS.Models.Article> IndexOperater { get; set; }
        [Dependency("DetailOperater")]
        public IEntityKeyView<CMS.Models.Article, int> DetailOperater { get; set; }
        [Dependency("CreateOperater")]
        public IEntityAdd<CMS.Models.Article> CreateOperater { get; set; }
        [Dependency("EditOperater")]
        public IEntityUpdate<CMS.Models.Article> EditOperater { get; set; }
        [Dependency("DeleteOperater")]
        public IEntityKeyDel<int> DeleteOperater { get; set; }
        #endregion
DI配置 
        public ActionResult Index()
        {
            var operater = IndexOperater;
            IEnumerable<CMS.Models.Article> list = null;
            if (operater != null)
                list = operater.ListAll();
            return View(list ?? Enumerable.Empty<CMS.Models.Article>());
        }

是不是简单到"不可理喻,一点都看不出Dapper痕迹,要的就是这个效果

注:DI没看懂的请参看另一篇文章“Mvc扩展框架及DI”

4、看一下执行效果

不只是一个简单的列表,所有的添、删、改、查都实现了

5、有人不信是Dapper,那我调试给诸位看

6、有人说Dapper是基于sql的,你的sql在哪里？look配置

      <container name="CMS">
        <register type="Fang.Mvc.Area, Fang.Mvc" name="CMS">
          <lifetime type="singleton" />
          <property name="Name" type="string" value="CMS"></property>
          <property name="DependencyContainer" type="string" value="Mvc.CMS"></property>
          <!--<property name="Path" type="string" value="CMS"></property>-->
          <property name="NameSpaces">
            <array>
              <value value="CMS.Web.Controllers" />
            </array>
          </property>
        </register>
        
        <register type="Fang.Data.IEntityList[[CMS.Models.Article, CMS.Models]], Fang.Interface"  mapTo="Fang.FangDapper.SqlListAll[[CMS.Models.Article, CMS.Models]], Fang.FangDapper" name="IndexOperater">
          <lifetime type="singleton" />
          <property name="Sql" type="string" value="SELECT [Id],[Title],[BodyId],[UserId] FROM [dbo].[Article] WITH(NOLOCK) ORDER BY [Id] DESC"></property>
          <property name="Config">
            <optional name="jinrong_log_ReadDb" type="Fang.ADO.ConnectionStringFactory, Fang.ADO" />
          </property>
        </register>

        <register type="Fang.Data.IEntityKeyView[[CMS.Models.Article, CMS.Models],int], Fang.Interface"  mapTo="Fang.FangDapper.SqlViewByKey[[CMS.Models.Article, CMS.Models],int], Fang.FangDapper" name="DetailOperater">
          <lifetime type="singleton" />
          <property name="Sql" type="string" value="SELECT [Id],[Title],[BodyId],[UserId] FROM [dbo].[Article] WITH(NOLOCK) WHERE [Id]=@id"></property>
          <property name="Config">
            <optional name="jinrong_log_ReadDb" type="Fang.ADO.ConnectionStringFactory, Fang.ADO" />
          </property>
        </register>

        <register type="Fang.Data.IEntityAdd[[CMS.Models.Article, CMS.Models]], Fang.Interface"  mapTo="Fang.FangDapper.SqlAdd[[CMS.Models.Article, CMS.Models]], Fang.FangDapper" name="CreateOperater">
          <lifetime type="singleton" />
          <property name="Sql" type="string" value="INSERT INTO [dbo].[Article]([Title],[BodyId],[UserId]) VALUES(@Title,@BodyId,@UserId)"></property>
          <property name="Config">
            <optional name="jinrong_log_WriteDb" type="Fang.ADO.ConnectionStringFactory, Fang.ADO" />
          </property>
        </register>

        <register type="Fang.Data.IEntityUpdate[[CMS.Models.Article, CMS.Models]], Fang.Interface"  mapTo="Fang.FangDapper.SqlUpdate[[CMS.Models.Article, CMS.Models]], Fang.FangDapper" name="EditOperater">
          <lifetime type="singleton" />
          <property name="Sql" type="string" value="UPDATE [dbo].[Article] SET [Title]=@Title,[BodyId]=@BodyId,[UserId]=@UserId WHERE [Id]=@id"></property>
          <property name="Config">
            <optional name="jinrong_log_WriteDb" type="Fang.ADO.ConnectionStringFactory, Fang.ADO" />
          </property>
        </register>

        <register type="Fang.Data.IEntityKeyDel[int], Fang.Interface"  mapTo="Fang.FangDapper.SqlDelByKey[[CMS.Models.Article, CMS.Models],int], Fang.FangDapper" name="DeleteOperater">
          <lifetime type="singleton" />
          <property name="Sql" type="string" value="DELETE [dbo].[Article] WHERE [Id]=@id"></property>
          <property name="Config">
            <optional name="jinrong_log_WriteDb" type="Fang.ADO.ConnectionStringFactory, Fang.ADO" />
          </property>
        </register>

        <!--数据库读-->
        <register type="Fang.ADO.ConnectionStringFactory, Fang.ADO" name="jinrong_log_ReadDb">
          <lifetime type="singleton" />
          <property name="Name" type="string" value="jinrong_log_ReadDb"></property>
        </register>
        <!--数据库写-->
        <register type="Fang.ADO.ConnectionStringFactory, Fang.ADO" name="jinrong_log_WriteDb">
          <lifetime type="singleton" />
          <property name="Name" type="string" value="jinrong_log_WriteDb"></property>
        </register>
        <!--容器自动初始化列表配置-->
        <register type="Fang.UnitOfWork.IUnitInit, Fang.Interface" mapTo="Fang.UnitOfWork.MutiUnitInit, Fang.Framework" name="ContainerInit">
          <lifetime type="singleton" />
          <property name="Objs">
            <array>
              <optional name="jinrong_log_ReadDb" type="Fang.ADO.ConnectionStringFactory, Fang.ADO" />
              <optional name="jinrong_log_WriteDb" type="Fang.ADO.ConnectionStringFactory, Fang.ADO" />
            </array>
          </property>
        </register>
      </container>
Mvc分区及DI容器配置

注:以上是Unity容器配置,不用Unity用其他容器也是可以的(只是配置格式稍有不同,不用配置文件用代码注入也是可以的)

我看着还是挺漂亮的,实现Dapper扩展之后完全彻底颠覆了我对Dapper的印象,非常灵活、非常强大、非常简单。

7、再把其他几个视图也简单截图赏析一下

 

三、以上功能再用EF实现一次

1、MVC都是一样的,直接看执行效果图

和前面截图几乎一样,有几个小区别,其一Url不一样,是同一个应用程序(站点)下的另一个分区,排序稍有不同,这个是正序(Dapper是倒序,不用纠结)

2、那怎么证明是EF实现的呢？直接调试进去就可以看到了

3、EF这些都是靠容器配置实现的,我们也看一下EF这个分区怎么配置的

      <container name="CMS2">
        <register type="Fang.Mvc.Area, Fang.Mvc" name="CMS2">
          <lifetime type="singleton" />
          <property name="Name" type="string" value="CMS2"></property>
          <property name="DependencyContainer" type="string" value="Mvc.CMS2"></property>
          <property name="Path" type="string" value="CMS2"></property>
          <property name="NameSpaces">
            <array>
              <value value="CMS.Web.Controllers" />
            </array>
          </property>
        </register>
        <register type="Fang.Data.IEntityList[[CMS.Models.Article, CMS.Models]], Fang.Interface"  mapTo="Fang.EF.Repository[[CMS.Models.Article, CMS.Models]], Fang.EF" name="IndexOperater">
          <lifetime type="singleton" />
          <property name="NameOrConnectionString" type="string" value="name=jinrong_log_ReadDb"></property>
          <property name="Configuration">
            <optional name="TableFactory" type="Fang.EF.TableFactory[[CMS.Models.Article, CMS.Models]], Fang.EF" />
          </property>
        </register>

        <register type="Fang.Data.IEntityKeyView[[CMS.Models.Article, CMS.Models],int], Fang.Interface"  mapTo="Fang.EF.RepositoryWithKey[[CMS.Models.Article, CMS.Models],int], Fang.EF" name="DetailOperater">
          <lifetime type="singleton" />
          <property name="NameOrConnectionString" type="string" value="name=jinrong_log_ReadDb"></property>
          <property name="Configuration">
            <optional name="TableFactory" type="Fang.EF.TableFactory[[CMS.Models.Article, CMS.Models]], Fang.EF" />
          </property>
        </register>

        <register type="Fang.Data.IEntityAdd[[CMS.Models.Article, CMS.Models]], Fang.Interface"  mapTo="Fang.EF.Repository[[CMS.Models.Article, CMS.Models]], Fang.EF" name="CreateOperater">
          <lifetime type="singleton" />
          <property name="NameOrConnectionString" type="string" value="name=jinrong_log_WriteDb"></property>
          <property name="Configuration">
            <optional name="TableFactory" type="Fang.EF.TableFactory[[CMS.Models.Article, CMS.Models]], Fang.EF" />
          </property>
        </register>

        <register type="Fang.Data.IEntityUpdate[[CMS.Models.Article, CMS.Models]], Fang.Interface"  mapTo="Fang.EF.Repository[[CMS.Models.Article, CMS.Models]], Fang.EF" name="EditOperater">
          <lifetime type="singleton" />
          <property name="NameOrConnectionString" type="string" value="name=jinrong_log_WriteDb"></property>
          <property name="Configuration">
            <optional name="TableFactory" type="Fang.EF.TableFactory[[CMS.Models.Article, CMS.Models]], Fang.EF" />
          </property>
        </register>

        <register type="Fang.Data.IEntityKeyDel[int], Fang.Interface"  mapTo="Fang.EF.RepositoryWithKey[[CMS.Models.Article, CMS.Models],int], Fang.EF" name="DeleteOperater">
          <lifetime type="singleton" />
          <property name="NameOrConnectionString" type="string" value="name=jinrong_log_WriteDb"></property>
          <property name="Configuration">
            <optional name="TableFactory" type="Fang.EF.TableFactory[[CMS.Models.Article, CMS.Models]], Fang.EF" />
          </property>
        </register>

        <!--TableFactory-->
        <register type="Fang.EF.TableFactory[[CMS.Models.Article, CMS.Models]], Fang.EF" name="TableFactory">
          <lifetime type="singleton" />
          <property name="Table" type="string" value="Article"></property>
          <property name="MappingRule">
            <optional name="ArticleMapping"  type="CMS.EF.ArticleMapping, CMS.EF" />
          </property>
        </register>
        <register type="CMS.EF.ArticleMapping, CMS.EF" name="ArticleMapping">
          <lifetime type="singleton" />
        </register>
      </container>
EF分区及DI容器配置

是不是完全颠覆对以前对EF认知

领域建模是在容器配置中,想建几个建几个,想把哪几个表建一组就建一组,分库分表读写分离全部不在话下

(这里有个小小的问题没解决,同一个领域(DbContext)不能支持同类型的两张表,多用几个DbContext就没问题了)

通过以上接口实现了ORM工具和MVC的彻底分离,要换ORM工具那是“分分钟”的事,M(Model)V(View)C(Controller)都不用改;更喜出望外的是可以搭配任意种ORM工具,不用太纠结ORM工具选型的问题上

也不存在ORM选型失败导致整个项目重做的风险(ORM还原为一个辅助开发工具角色,而不是基础架构本身的一部分)

4、EF建模解析

常人对EF的认识中EF模型都是特殊的,使用edmx或者T4模板来自动生成各种奇怪的代码,这里怎么不要呢？有简单和大家分享一下

4.1 EF可以通过EntityTypeConfiguration和ComplexTypeConfiguration两种来配置表名、主键、含有字段及其类型和约束

注:大家直接百度就可以找到很多资料

4.2 我对DbContext进行扩展,加载自己定义的配置信息

4.3 ArticleMapping就是我定义的一个修改映射的类型

    /// <summary>
    /// Article表字段映射配置
    /// </summary>
    public class ArticleMapping : IEntityOperate<StructuralTypeConfiguration<Article>>
    {
        /// <summary>
        /// 字段映射配置
        /// </summary>
        /// <param name="entity"></param>
        /// <returns></returns>
        public bool Acion(ref StructuralTypeConfiguration<Article> entity)
        {
            EntityTypeConfiguration<Article> config = entity as EntityTypeConfiguration<Article>;
            if (config == null)
                return false;
            config.HasKey<int>(article => article.Id);
            return true;
        }
    }
ArticleMapping

这个映射比较简单,就是定义了一个主键(没有主键,很多功能不能用)

 

四、为什么选EntityFramework和Dapper

1、显而易见,EntityFramework和Dapper是应用最广泛的两种ORM工具,前面已经说的比较清楚

2、为什么是两个不是其中一个

EntityFramework和Dapper是两种工作方式完全不同的ORM工具，且有高度的互补性

2.1 Dapper直接基于sql,对一般开发者更加简单容易接受,而且更容易做纯粹sql的性能优化

2.2 EntityFramework是基于领域建模,可以实现复杂的业务模型对象关系

　　但是EntityFramework生成的sql的性能实在不敢恭维,如果出现性能问题很难优化,这个时候把EntityFramework生成有性能问题的sql打印出来优化后再交给Dapper来处理就非常简单

2.3 互补分工如下：

　　复杂对象关系交给EntityFramework

　　sql性能优化交给Dapper

　　其他的简单数据库操作他们两个都能很好的处理,就看团队的技术倾向;更喜欢看sql的团队,尽量用Dapper;去sql化的团队就尽量用EntityFramework

　　注:至于我原来开发的ORM工具介于两者之间,本来我正在升级版本以便更好使用面向接口方式开发,现在我决定放弃了。因为随着对EntityFramework和Dapper的熟悉,这种中间态的ORM工具没有竞争优势还增加工程师的学习成本(对于用习惯了我的ORM工具的同事,我只能说声抱歉,对你们也许也算一种解脱,让我们一起投入到EntityFramework+Dapper的怀抱)。

注:当然也不是说其他ORM工具就一无是处,以后看受众群体情况再增加其他ORM工具扩展的选项

 

先写到这里,希望大家喜欢。

 

文章标签：
SQL
容器
数据处理
.NET
前端开发
关键词：
.NET接口
ASP接口
ASP.NET接口
.NET框架
ASP框架
杰克.陈
目录
相关文章
Net分享
|
19天前
|
消息中间件 开发框架 监控
NET任务调度框架Hangfire使用指南
Hangfire 是一个用于 .NET 应用程序的开源任务调度框架，支持长时间运行任务、定时任务等。通过简单的安装配置，即可将任务从主线程分离，提升应用性能。支持多种数据库，提供丰富的任务类型如立即执行、延迟执行和周期性任务，并有可视化管理界面 Hangfire Dashboard。还支持安全性配置及扩展插件，如 Hangfire.HttpJob，适合各种复杂场景下的任务调度需求。
Net分享
42 1
NET任务调度框架Hangfire使用指南
蓝易云
|
14天前
|
开发框架 监控 .NET
C#进阶-ASP.NET WebForms调用ASMX的WebService接口
通过本文的介绍，希望您能深入理解并掌握ASP.NET WebForms中调用ASMX WebService接口的方法和技巧，并在实际项目中灵活运用这些技术，提高开发效率和应用性能。
蓝易云
31 5
土木林森
|
1月前
|
开发框架 安全 .NET
在数字化时代，.NET 技术凭借跨平台兼容性、丰富的开发工具和框架、高效的性能及强大的安全稳定性，成为软件开发的重要支柱
在数字化时代，.NET 技术凭借跨平台兼容性、丰富的开发工具和框架、高效的性能及强大的安全稳定性，成为软件开发的重要支柱。它不仅加速了应用开发进程，提升了开发质量和可靠性，还促进了创新和业务发展，培养了专业人才和技术社区，为软件开发和数字化转型做出了重要贡献。
土木林森
27 5
东方睿赢
|
1月前
|
传感器 人工智能 供应链
.NET开发技术在数字化时代的创新作用，从高效的开发环境、强大的性能表现、丰富的库和框架资源等方面揭示了其关键优势。
本文深入探讨了.NET开发技术在数字化时代的创新作用，从高效的开发环境、强大的性能表现、丰富的库和框架资源等方面揭示了其关键优势。通过企业级应用、Web应用及移动应用的创新案例，展示了.NET在各领域的广泛应用和巨大潜力。展望未来，.NET将与新兴技术深度融合，拓展跨平台开发，推动云原生应用发展，持续创新。
东方睿赢
43 4
土木林森
|
1月前
|
开发框架 .NET C#
.NET 技术凭借高效开发环境、强大框架支持及跨平台特性，在软件开发中占据重要地位
.NET 技术凭借高效开发环境、强大框架支持及跨平台特性，在软件开发中占据重要地位。从企业应用到电子商务，再到移动开发，.NET 均展现出卓越性能，助力开发者提升效率与项目质量，推动行业持续发展。
土木林森
32 4
追逐时光者
|
1月前
|
消息中间件 监控 数据可视化
基于.NET开源、功能强大且灵活的工作流引擎框架
基于.NET开源、功能强大且灵活的工作流引擎框架
追逐时光者
44 3
追逐时光者
|
1月前
|
开发框架 网络协议 .NET
C#/.NET/.NET Core优秀项目和框架2024年10月简报
C#/.NET/.NET Core优秀项目和框架2024年10月简报
追逐时光者
66 3
追逐时光者
|
1月前
|
网络协议 Unix Linux
精选2款C#/.NET开源且功能强大的网络通信框架
精选2款C#/.NET开源且功能强大的网络通信框架
追逐时光者
51 0
追逐时光者
|
1月前
|
开发框架 JavaScript 前端开发
2024年全面且功能强大的.NET快速开发框架推荐，效率提升利器！
2024年全面且功能强大的.NET快速开发框架推荐，效率提升利器！
追逐时光者
64 0
追逐时光者
|
1月前
|
网络协议 网络安全 Apache
一个整合性、功能丰富的.NET网络通信框架
一个整合性、功能丰富的.NET网络通信框架
追逐时光者
39 0

热门文章

最新文章

  • 1
    （已解决）Linux环境—bash: wget: command not found； Docker pull报错Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
  • 2
    【Azure Function App】Azure Function 从.Net6 升级到 .Net8 后 Function出现运行时版本错误
  • 3
    基于云效 Windows 构建环境和 Nuget 制品仓库进行 .Net 应用开发
  • 4
    Benchmark.NET：让 C# 测试程序性能变得既酷又简单
  • 5
    驾驭Autofac，ASP.NET WebApi实现依赖注入详细步骤总结
  • 6
    .net8 Syncfusion生成pdf/doc/xls/ppt最新版本
  • 7
    NET任务调度框架Hangfire使用指南
  • 8
    .net HTTP请求类封装
  • 9
    ASP.NET Web Pages - 教程
  • 10
    简化 ASP.NET Core 依赖注入（DI）注册-Scrutor
  • 1
    LabVIEW加载.NET程序集
    111
  • 2
    LabVIEW中使用.NET方法时出现错误1316
    125
  • 3
    LabVIEW中加载.NET 2.0,3.0和3.5程序集
    175
  • 4
    .NET Compact Framework下的GPS NMEA data数据分析（二）转
    50
  • 5
    ASP.NET AJAX使用方法概述（三）
    64
  • 6
    Asp.net 2.0专题之一：MasterPage（2）
    43
  • 7
    使用PyTorch实现L1, L2和Elastic Net正则化
    104
  • 8
    C#/ASP.NET应用程序配置文件app.config/web.config的增、删、改操作
    81
  • 9
    Asp.net 2.0专题之一：MasterPage(2)
    42
  • 10
    安装ASP.NET AJAX (一安装)
    118

    • 相关电子书

    更多
  • 如何利用Redisson分布式化传统Web项目
  • PostgresChina2018_桑栎_PipelineDB体系结构和使用场景(1)
  • Web应用系统性能优化

    • 相关实验场景

    更多
  • 语言入门-1：环境构建
  • 使用Java面向对象编写网络通信程序应用
  • Python网络通信程序典型应用
  • 基于函数计算快速搭建Zblog等传统应用框架
  • 搭建Java Web开发环境
    • 下一篇
    手把手教你白嫖阿里云服务器(免费领服务器)