2. 程式人生 > >Asp.net 面向介面可擴充套件框架之資料處理模組及EntityFramework擴充套件和Dapper擴充套件(含乾貨)

Asp.net 面向介面可擴充套件框架之資料處理模組及EntityFramework擴充套件和Dapper擴充套件(含乾貨)

阿新 • • 發佈：2018-11-14
原文: 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][email protected]"></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][email protected],[BodyId][email protected],[UserId][email protected] WHERE [Id][email protected]"></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][email protected]"></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工具擴充套件的選項

 

先寫到這裡,希望大家喜歡。

 

相關推薦

Asp.net 面向介面可擴充套件框架之資料處理模組及EntityFramework擴充套件和Dapper擴充套件(含乾貨)

原文: Asp.net 面向介面可擴充套件框架之資料處理模組及EntityFramework擴充套件和Dapper擴充套件(含乾貨) 介面資料處理模組是什麼意思呢？實際上很簡單,就是使用面向介面的思想和方式來做資料處理。 還提到EntityFramework和Dapper,EntityFramework和

Asp.net 面向介面可擴充套件框架之業務規則引擎擴充套件元件

原文: Asp.net 面向介面可擴充套件框架之業務規則引擎擴充套件元件 隨著面向介面可擴充套件框架的繼續開發,有些功能開發出現了"瓶頸",有太多的東西要寫死才好做。但寫死的程式碼擴充套件性是非常的不好,迷茫中尋找出入... 進而想到我以前開發的好幾個專案,都已有一定的可配置能力,想想怎麼把這些地方的程式

RDIFramework.NET ━ .NET快速資訊化系統開發框架 V3.2->新增模組管理介面匯出功能（可按條件匯出）

匯出功能在很多應用場景中都需要，RDIFramework.NET V3.2版本在模組管理介面新增了匯出功能，方便管理員對所有配置的模組進行管理。 一、Web版模組管理匯出功能 Web版本的模組匯出功能如下圖所示：   單擊匯出按鈕，在彈出的“匯出Excel資料”視窗中，可以選擇要匯出的列，如下圖所

ASP.NET面向角色授權之：自定義Forms使用者驗證與授權

流程 一、配置config n  基本內容 <configuration> <system.web> <authenticationmode="Forms"> <formsname=".WroxDemo" loginUrl="l

ASP.NET Core 奇技淫巧之介面代理轉發

前言 先講講本文的開發背景吧.. 在如今前後端分離的大背景下,咱的客戶又有要求啦~ 要前後端分離~ 然因為種種原因..沒辦法用用純前端的框架(其實是學習成本高,又沒錢請前端開發人員)... 所以最終決定了一種方案.. 那就是採用MVC(只處理前端檢視層,單純是為了託管在.net core上)+Webapi的方

asp.net core的身份驗證框架IdentityServer4特性一覽

google 工作流 定制 聯合 特性 tor 中控 www directory IdentityServer4是ASP.NET Core的一個包含OpenID和OAuth 2.0協議的框架。OpenID和OAuth 的區別請看 https://www.zhihu.com/

ASP.NET沒有魔法——ASP.NET MVC 與數據庫之ORM

設計器 不同類 使用 運行程序 relation 編譯 如何 n) and 什麽是ORM 　　對象關系映射（Object Relational Mapping，簡稱ORM，或O/RM，或O/R mapping），是一種程序技術，用於實現面向對象編程語言裏不同類型系統的數據

ASP.NET沒有魔法——ASP.NET MVC 與數據庫之EntityFramework配置與連接字符串

client frame view 必須 多個數據庫 epo get base fault 　　前幾篇文章中介紹了如何使用Entity Framework來操作數據庫，但是對EF的配置、連接字符串的指定仍然存在一些疑問。　　本章將對EF的配置進行介紹。　　EF可以通過兩種方

ASP.NET沒有魔法——ASP.NET MVC 與數據庫之MySQL&EF

dll 程序 connector resolv rdquo ram key log 找到 　　本章將介紹如何通過Entity Framework來使用My SQL，之前介紹EF時介紹了provider這個配置項，而且也介紹了在ASP.NET訪問MySQL數據仍然是通過ADO

ASP.NET沒有魔法——ASP.NET MVC 與數據庫之EF實體類與數據庫結構

類之間的關系 context 模型 rst 例子 style 方法 eid 一個 　　大家都知道在關系型數據庫中每張表的每個字段都會有自己的屬性，如：數據類型、長度、是否為空、主外鍵、索引以及表與表之間的關系。但對於C#編寫的類來說，它的屬性只有一個數據類型和類與類之間的關

Asp.net 與 UCenter 用戶同步之實施過程

framework hosts dcl eba exec apt pick summary sts 在寫這篇文章的時候，我還在想，這篇文章也許能給你帶來一些收獲，但或許會令你更加的迷茫，為什麽會這樣？因為：1、UCenter雖然足夠強大，但正為它的強大，它的不少暗箱操作

ASP.NET SignalR 系列（九）之源碼與總結

pan ie7 集線器 增加 地址 註意 ocs pac mic 1、SignalR 1.0與2.0有些不同，以上篇章均只支持2.0+ 2、必須註意客戶端調用服務端對象和方法時的大小寫問題 3、客戶端上的方法不能重名 4、IE7及以下的，需要增加json的分析器，分析器下載

微服務介紹及Asp.net Core實戰項目系列之微服務介紹

管理 col 數據強一致性 pan 基於 數據存儲 tlab fdm 人的 0、目錄 整體架構目錄：ASP.NET Core分布式項目實戰-目錄 一、微服務選型 在做微服務架構的技術選型的時候，以“無侵入”和“社區活躍”為主要的考量點，將來升級為原子服務架構、量子

ASP.NET Core 中的物件對映之 AutoMapper

目錄 AutoMapper 簡介 AutoMapper 使用 初始化 Profile設定 扁平化對映 集合對映 投影 條件對映 值轉換 設定轉換前後行為 配置驗證及設定 反向對映 自定義轉換器 自

HTTP介面自動化經驗總結（三）Okhttp3 介面測試框架搭建之資料處理

上篇文章寫了怎麼新建POST，GET方法。這篇文章介紹下該如何校驗。 因為我們在方法裡面都返回了String型別結果，String型別校驗起來比較麻煩。多數http介面返回的都是json形式。我們可以寫一個通用方法將String型別轉換為Map物件這樣校驗就比較方便準確了。廢話不多說直接上方法。

Python+Requests+Unittest+Excel 介面自動化測試框架之Request模組01

1.Requests模組  a.Request模組是Python中可以實現模擬Http協議的模組  b.安裝方式很多，可以用pip install requests 2.舉例 import requests class Http_Request:     #定義一個請求函

如何提高碼農產量，基於ASP.NET MVC的敏捷開發框架開發隨筆一

公司業務量比較大，接了很多專案，為了縮短開發週期老闆讓我牽頭搭建了一個敏捷開發框架。 我們主要的業務是做OA、CRM、ERP一類的管理系統，一個通用的後臺搭出來，再配合一些快速開發的元件開發效率能提高很多。 另外老闆一再強調要支援APP開發，一次開發能部署到安卓和IOS上。

ASP.NET Core的身份認證框架IdentityServer4（9）-使用OpenID Connect新增使用者認證

原文: ASP.NET Core的身份認證框架IdentityServer4（9）-使用OpenID Connect新增使用者認證 OpenID Connect OpenID Connect 1.0是OAuth 2.0協議之上的一個簡單的身份層。 它允許客戶端基於授權伺服器執行的身份驗證來驗證終端使用者的

ASP.NET Core的身份認證框架IdentityServer4（3）-術語的解釋

IdentityServer4 術語 IdentityServer4的規範、文件和物件模型使用了一些你應該瞭解的術語。 身份認證伺服器（IdentityServer） IdentityServer是一個OpenID Connect提供程式，它實現了OpenID Connect 和 OAuth 2.0 協議。

ASP.NET Core開發-使用Nancy框架

原文: ASP.NET Core開發-使用Nancy框架 Nancy簡介 Nancy是一個輕量級的獨立的框架，下面是官網的一些介紹: Nancy 是一個輕量級用於構建基於 HTTP 的 Web 服務，基於 .NET 和 Mono 平臺，框架的目標是保持儘可能多的方式，並提供一個super-dupe