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 interface1、IEntityIEntity<TPrimaryKey> : IEntity { /// <summary> /// 主鍵 /// </summary> TPrimaryKey Id { get; set; } } /// <summary> /// 實體介面 /// </summary> public interface IEntity { /// <summary> /// 主鍵 /// </summary> object ObjId { get; } }
注:主鍵是泛型(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; } #endregionDI配置
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工具擴充套件的選項
先寫到這裡,希望大家喜歡。