手把手教你:让EF动态支持新增表、动态支持多数据库

名词解释:此动态非运行时动态,让EF动态支持新增表、动态切换数据库意在不改变项目核心框架,

通过新增或者替换组件的方式达到标题目地。

 

一、先来点简单的,动态支持多数据库

AppDbContext实现:

<span class="kwrd">public</span> <span class="kwrd">class</span> AppDbContext:DbContext
    {
        <span class="kwrd">public</span> AppDbContext(<span class="kwrd">string</span> configKey)
            : base(configKey)
        {
 
        }
 
        <span class="kwrd">protected</span> <span class="kwrd">override</span> <span class="kwrd">void</span> OnModelCreating(DbModelBuilder modelBuilder)
        {
            <span class="kwrd">base</span>.OnModelCreating(modelBuilder);
        }
    }

在AppDbContext构造函数中添加configKey参数,通过configKey参数指定配置文件中的连接字符串的配置项;

 

创建IDbContextProvider接口,如下:

<span class="kwrd">public</span> <span class="kwrd">interface</span> IDbContextProvider
    {
        AppDbContext Get();
    }

意图很明显了,通过IDbContextProvider来提供AppDbContext,这样我们首先将AppDbContext与业务层解耦;

 

继续创建2个项目:MsSqlProvider、MySqlProvider,分别实现IDbContextProvider接口:

MsSql:

<span class="kwrd">public</span> <span class="kwrd">class</span> MsSqlProvider:IDbContextProvider
    {
        AppDbContext m_AppDbContext = <span class="kwrd">null</span>;
 
        <span class="kwrd">public</span> AppDbContext Get()
        {
            <span class="kwrd">return</span> m_AppDbContext ?? <span class="kwrd">new</span> AppDbContext(<span class="str">"MsSql"</span>);
        }
    }

MySQL:

  <span class="kwrd">public</span> <span class="kwrd">class</span> MySqlProvider:IDbContextProvider
    {
        AppDbContext m_AppDbContext = <span class="kwrd">null</span>;
 
        <span class="kwrd">public</span> AppDbContext Get()
        {
            <span class="kwrd">return</span> m_AppDbContext ?? <span class="kwrd">new</span> AppDbContext(<span class="str">"MySql"</span>);
        }
    }

下面继续解释动态支持/切换DbContextProvider,没错…聪明的你一开始就应该想到了..依赖注入,这个时候我们就需要使用依赖注入来完成使命了;

我已MEF为例来演示下如何动态获取2种DbContextProvider:

首先为我们的IDbContextProvider添加 [InheritedExport] 标记,然后分别为两种Provider添加 [Export]标记;

 

"MEF的使用还请大家自己去熟悉,我也仅仅是会使用而已,并不精通"

 

接着在Demo中添加App.Config和测试代码;

App.Config:

<?xml version=<span class="str">"1.0"</span> encoding=<span class="str">"utf-8"</span> ?>
<configuration>
  <connectionStrings>
    <add name="MsSql" connectionString="Data Source=LIANG-HU-PC;Initial Catalog=appbase;Integrated Security=True;Pooling=False" providerName="System.Data.SqlClient" />
    <add name=<span class="str">"MySql"</span> connectionString=<span class="str">"server=localhost;User Id=root;password=mysql;Persist Security Info=True;database=appbase"</span> providerName=<span class="str">"MySql.Data.MySqlClient"</span> />
  </connectionStrings>
</configuration>

这里要提醒下哦:要使MySql能够支持EF使用的话,需要到MySql官方下载最新的驱动;

测试代码如下:

 <span class="kwrd">class</span> Program
    {
        [ImportMany]
        static IEnumerable<IDbContextProvider> m_Providers = null;
 
        static void Main(string[] args)
        {
            //使用目录方式查找MEF部件
            var catalog = <span class="kwrd">new</span> DirectoryCatalog(AppDomain.CurrentDomain.BaseDirectory);
 
            <span class="rem">//创建Container</span>
            var container = new CompositionContainer(catalog);
 
            //获取Export项,这里直接加载不采用Lazy
            m_Providers = container.GetExportedValues<IDbContextProvider>();
            if (m_Providers != null)
            {
                foreach (var provider in m_Providers)
                {
                    Console.WriteLine(provider.Get().Database.Connection.ConnectionString);
                }
            }
            Console.ReadKey(<span class="kwrd">false</span>);
        }

OK,我们来编译测试下,当应用程序目录下没有任何Provider的时候是没有获取到任何是不会获取到任何Provider的,如果只放置MySqlProvider再执行的话结果如下:

image

放置两项Provider组件的时候自然就会是两个都被获取到,我就不演示了;

 

到这里可能很多人就要嘘声一片了,也许你会提出一些问题:

比如:

1)为什么不做一个Provider的实现,在Get()方法或者构造函数中依赖注入参数呢?

其实这样做的目地是我们在使用UnitOfWork和Repository模式时能够简单方便的获取DbContext;

可参见示例:

    <span class="rem">/// <summary></span>
    /// Entity Framework Repository
    <span class="rem">/// </summary></span>
    /// <typeparam name="T"></typeparam>
    <span class="kwrd">public</span> <span class="kwrd">class</span> EFRepository<T>:IRepository<T>
        where T:class
    {
        readonly IDataBaseFactory m_DataBaseFactory = null;
 
        public EFRepository(IDataBaseFactory dataBaseFactory)
        {
            if(dataBaseFactory==null)
            {
                throw new ArgumentNullException("DataBaseFactory");
            }
            m_DataBaseFactory=dataBaseFactory;
        }
 
        DbContext m_DbContext = <span class="kwrd">null</span>;
 
        <span class="kwrd">protected</span> DbContext DbContext
        {
            get
            {
                <span class="kwrd">return</span> m_DbContext ?? m_DataBaseFactory.Get();
            }
        }
对UnitOfWork模式的使用与此类似;
 
 

2)我只需要一个DbContext,但有时候需要切换数据库,那怎么办呢?

这个问题是ico与依赖注入方面的基础内容,需要您自己去学习哦;

 

至此,简单的“动态”支持多数据库示例就完成了~~~ 我们的关键还是动态支持新建表,下面我们就来一步一步实践吧;

 

二、“动态”支持新建表,计划先行

首先我们创建ModelBase类库,存放一些与实体相关的接口和基类,结构如图所示:

image根据项目结构,我需要给大家解释每个文件的存在意义;

 

IEntity接口与AbstractEntityBase类,顾名思义,大家应该猜得到它们是实体基类,为什么要如此定义呢,主要是方便我们写实体的时候直接继承Id属性,(因为我们的所有表主键都是Guid且名为Id)

<span class="kwrd">public</span> <span class="kwrd">interface</span> IEntity
    {
        Guid Id { get; }
    }
<span class="kwrd">public</span> <span class="kwrd">abstract</span> <span class="kwrd">class</span> AbstractEntityBase : IEntity
    {
        <span class="kwrd">public</span> AbstractEntityBase()
        {
            <span class="kwrd">this</span>.Id = Guid.NewGuid();
        }
 
        [Key]
        [Required]
        public Guid Id
        {
            get;
            <span class="kwrd">protected</span> set;
        }
    }

还有一个好处就是我们直接在基类中描述 主键关系,在写实体的时候直接继承后,可以省去很多重复操作哦^_^

 

再来说IMapping和Mapping,为什么要有这2个基类接口呢,出于以下方面考虑:

1)将实体与数据库的映射关系产生Mapping类与DbContext类解耦(这个会在下面具体出现时再说)

2)通过MappingBase基类实现一些公共操作,避免每个实体类的重复操作,具体看代码你就会明白;

 [InheritedExport]
    public interface IMapping
    {
        void RegistTo(ConfigurationRegistrar configurationRegistrar);
    }
public class MappingBase<TEntity> : EntityTypeConfiguration<TEntity>, IMapping
        <span class="kwrd">where</span> TEntity : <span class="kwrd">class</span>,IEntity
    {
        <span class="kwrd">public</span> MappingBase()
        {
            <span class="kwrd">this</span>.Map(m => m.ToTable(<span class="kwrd">typeof</span>(TEntity).Name));
        }
 
        public void RegistTo(ConfigurationRegistrar configurationRegistrar)
        {
            configurationRegistrar.Add(this);
        }
    }

呵呵,有了“动态”支持多数据库,这里很多人应该就能猜到我们如何“动态”支持新增表咯;注意这里的IMapping接口的精妙所在哦,您发现了吗???;

 

三、万事俱备,只欠东风

我们先在ModelA类库中创建一个User实体和Role实体,同时创建UserMapping和RoleMapping,(为什么要创建Mapping类,后面我会讲)

USer 、UserMapping:

 <span class="rem">/*</span>
     * 为什么没有通过[Table]来指明表明呢,
<span class="rem">     * 并不是因为我们需要EF自己支持的表明方式</span>
     * 而是我们继承自AbstractEntityBase,在其基类已经实现了将类名映射为表名
<span class="rem">     */</span>
    public class User : AbstractEntityBase
    {
        [Required]
        <span class="kwrd">public</span> <span class="kwrd">string</span> Username { get; set; }
 
        [Required]
        public string Password { get; set; }
 
        /*
<span class="rem">         * 注意这里,我为什么不通过DataAnnotations方式添加外键关联呢</span>
         * 个人认为User实体与Role实体关联,已经拥有Role属性了,
<span class="rem">         * 如果在添加一个RoleId来表示外键关系,会让我觉得User类不够清爽</span>
         * 所以我的做法是添加UserMapping类来指定它与Role实体的关系
<span class="rem">         * </span>
         * 但是有一点要注意,如果不指定外键的话,默认数据库外键是为 表名_主键(Role_Id)类型
<span class="rem">         */</span>
        public virtual Role Role{get;set;}
    }
 
[Export(<span class="str">"UserMapping"</span>)]
    public class UserMapping:MappingBase<User>
    {
        public UserMapping()
        {
            this.HasRequired(m => m.Role)
                .WithMany(m => m.Users);
            /*注意这里没有指定HasForeignKey哦*/
        }
    }

Role类和RoleMapping的实现也是同理,结合上面代码中的注释内容,我想大家也能够理解我的良苦用心了吧;如果还不能理解,我们再看下DbContext是如何实现的:

<span class="rem">/*</span>
     * 很清爽的DbContext,完全不包含任何DbSet
<span class="rem">     * 通过Mapping来加载表结构</span>
     */
    <span class="kwrd">public</span> <span class="kwrd">class</span> AppDbContext:DbContext
    {
        <span class="kwrd">public</span> AppDbContext(<span class="kwrd">string</span> configKey)
            : base(configKey)
        {
            //可以设置通过反向方式创建表哦,但是我们演示的目地不在于此
            <span class="rem">//Database.SetInitializer(new DropCreateDatabaseIfModelChanges<AppDbContext>());</span>
 
            <span class="rem">//加载目录下所有IMapping实现</span>
            var catalog = new DirectoryCatalog(AppDomain.CurrentDomain.BaseDirectory);
            var container = <span class="kwrd">new</span> CompositionContainer(catalog);
            m_Mappings = container.GetExportedValues<IMapping>();
        }
 
        [ImportMany]
        IEnumerable<IMapping> m_Mappings = null;
 
        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            if (m_Mappings != null)
            {
                //这里是关键
                <span class="kwrd">foreach</span> (var mapping <span class="kwrd">in</span> m_Mappings)
                {
                    mapping.RegistTo(modelBuilder.Configurations);
                }
            }
            base.OnModelCreating(modelBuilder);
        }
    }

 

没错,我们的目地就是让DbContext完全依靠IMapping去加载解释表结构关系,这样即保证DbContext不包含大量的DbSet,又能够非常好的将DbContext与实体解耦,

更重要的是,我们通过 DataAnnotations 和 Fluent API结合使用,让我们的实体也非常清爽;

 

到这里,其实我已经把核心的内容都展现出来了,对于新增表的动态使用也就类似与最前面讲的“动态”支持多数据库,我们只需要依赖注入所有的IMapping的实现,就可以让DbContext自动去解释所有表结构了(所以DbContext的OnModelCreating方法是关键所在)。

 

好,接着我们在新增一个ModelB 作为新增表NewModel实体的载体,来演示是我们的示例是否能够如题所描述的那样,不改变核心框架的前提下动态支持新增的表和实体。

 <span class="kwrd">public</span> <span class="kwrd">class</span> NewModel : AbstractEntityBase
    {
        [Required]
        public string Name { get; set; }
    }

 

我们按照之前做CmdDemo的方式添加一个AppDemo,并添加App.Config文件,同时创建一个DataViewControl的自定义控件用来显示数据;

我们来看下AppDemo的演示:

image

其具体实现为:

    <span class="rem">/// <summary></span>
    /// MainWindow.xaml 的交互逻辑
    <span class="rem">/// </summary></span>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }
 
        <span class="kwrd">private</span> <span class="kwrd">void</span> Window_Loaded(<span class="kwrd">object</span> sender, RoutedEventArgs e)
        {
            IDbContextProvider provider = <span class="kwrd">new</span> MsSqlProvider.MsSqlProvider();
            AppDbContext dbContext = provider.Get();
 
            var users = dbContext.Set<User>();
            <span class="kwrd">if</span> (users != <span class="kwrd">null</span>)
            {
                users.Add(<span class="kwrd">new</span> User()
                {
                    Username = <span class="str">"admin"</span>,
                    Password = "admin",
                    Role = <span class="kwrd">new</span> Role() { Name = <span class="str">"administrators"</span> }
                });
                dbContext.SaveChanges();
 
                DataViewControl usersViewControl=<span class="kwrd">new</span> DataViewControl();
                usersViewControl.Binding(users.ToList());
 
                TabItem item = new TabItem();
                item.Header = <span class="str">"User表展示"</span>;
                item.Content = usersViewControl;
 
                this.myTabControl.Items.Add(item);
            }
 
            var roles = dbContext.Set<Role>();
            if (roles != null)
            {
                DataViewControl rolesViewControl = new DataViewControl();
                rolesViewControl.Binding(roles.ToList());
 
                TabItem item = <span class="kwrd">new</span> TabItem();
                item.Header = "Role表展示";
                item.Content = rolesViewControl;
                this.myTabControl.Items.Add(item);
            }
 
            <span class="rem">/*</span>
             * 请注意此处,我们的NewModel还是和应用耦合在一起了,
<span class="rem">             * 并没有像我们标题说的动态加载;</span>
             * 这里主要是为了演示方便,我就不在做实体与业务层的解耦了,
<span class="rem">             * 一般我们的应用可能是单独的UI模块和它对应的实体耦合,而不是UI框架耦合</span>
             * 仅在需要的时候加载不同模块的UI组件
<span class="rem">             *</span>
             */
            var newModels = dbContext.Set<NewModel>();
            if (newModels != null)
            {
                DataViewControl newModelsViewControl = new DataViewControl();
                newModelsViewControl.Binding(newModels.ToList());
                TabItem item = new TabItem();
                item.Header = <span class="str">"NewModel表展示"</span>;
                item.Content = newModelsViewControl;
                <span class="kwrd">this</span>.myTabControl.Items.Add(item);
            }
        }
    }

 

需要解释的是AppDemo中没有很好的演示怎么动态支持新建表,其实我前面解释过ModelB中NewModel就是新增的表,主要是为了给大家展示实现思路,我并没有去把NewModel和AppDemo去解耦,所以没有很好的演示效果,但是实际上是没有问题的,这就跟我们具体的应用息息相关了。

到这里,我们已经完整的解释了整个过程,为此我也是边创建项目边写博客,在最后会附上完整项目源码,有兴趣的可以自行下载学习;如果这篇文章对你有所启发,或者让你学到了一些东西,那是我非常乐见的,同时也希望各位高手不要鄙视。

ef-orm A Simple OR-Mapping framework on multiple databases. 使用手册(中文)http://geequery.github.io/ef-orm/manual/EF-ORM-user-guide.docx  使用示例工程 https://github.com/GeeQuery/ef-orm/tree/master/orm-tutorial EF-ORM是一个轻量,便捷的Java ORM框架。并且具备若干企业级的应用特性,如分库分、JTA事务等。 代码生成插件for eclipse(请在eclipse中Help/Install new software后输入地址并安装)http://geequery.github.io/plugins/1.3.x/特点一 EF的设计的一个主要目的是提高开发效率,减少编码工作,让开发者“零配置”“少编码”的操作数据库大部分功能。 例如:数据库查询条件的传入问题是所有ORM框架都不能回避的一个问题,所以我经常在想——既然我们可以用向DAO传入一个Entity来实现插入操作,为什么就不能用同样的方法来描述一个不以主键为条件的update/select/delete操作?为什么DAO的接口参数老是变来变去?为什么很多应用中,自行设计开发类来描述各种业务查询条件才能传入DAO?为什么我们不能在数据访问层上花费更少的时间和精力?   JPA1.0和早期的H框架,其思想是将关系型数据库抽象为对象池,这极大的限制了本来非常灵活的SQL语句的发挥空间。而本质上,当我们调用某H框架的session.get、session.load、session.delete时,我们是想传递一个以对象形式达的数据库操作请求。只不过某H框架要求(并且限制)我们将其视作纯粹的“单个”对象而已。JPA 2.0为了弥补JPA1.0的不足,才将这种Query的思想引入为框架中的另一套查询体系——Criteria API。事实上针对单个对象的get/load/persist/save/update/merge/saveOrUpdate API和Criteria API本来就为一体,只不过是历史的原因被人为割裂成为两套数据库操作API罢了。   因此,对于关系型数据库而言——Entity和Query是一体两面的事物,所谓Query,可以包含各种复杂的查询条件,甚至可以作为一个完整的SQL操作请求的描述。为此,EF彻底将Entity和Query绑在了一起。这种思想,使得—— 开发人员需要编写的类更少。开发人员无需编写其他类来描述复杂的SQL查询条件。也无需编写代码将这些查询条件转换为SQL/HQL/JPQL。DAO层也不会有老要改来改去的接口和API,几乎可以做到零编码。 对单个对象进行CRUD的操作API现在和Criteria API合并在一起。Session对象可以直接提供原本要Criteria API才能提供实现的功能。API大大简化。 IQueryableEntity允许你将一个实体直接变化为一个查询(Query),在很多时候可以用来完成复杂条件下的数据查询。比如 ‘in (?,?,?)’, ‘Between 1 and 10’之类的条件。 xxQL有着拼装语句可读性差、编译器无法检查、变更维护困难等问题,但是却广受开发人员欢迎。这多少有历史原因,也有Criteria API设计上过于复杂的因素。两者一方是极端灵活但维护困难,一方是严谨强大而学习和编写繁琐,两边都是极端。事实上JPA的几种数据查询方式存在青黄不接的问题。选择查询语言xxQL,项目面临后续维护困难,跨数据库移植性差;选择Criteria API,代码臃肿,操作繁琐,很多人望而却步。EF的设计思想是使人早日摆脱拼装SQL/HQL/JPQL的困扰,而是用(更精简易用的)Criteria API来操作数据库。 基于轻量级Criteria API的操作方式,使得对数据库的变更和重构变得非常轻松,解决了SQL语句多对软件维护和移植造成产生的不利影响。 阅读推荐:第3、4章 特点二,将SQL的使用发挥到极致,解决SQL拼凑问题、数据库移植问题 大部分OLTP应用系统到最后都不免要使用SQL/JPQL,然而没有一个很好的方法解决SQL在多种数据库下兼容性的问题。 EF-ORM中采用了独特的SQL解析和改写技术,能够主动检查并确保SQL语句或者SQL片段在各个数据库上的兼容性。 EF中除了Criteria API以外,可以直接使用“SQL语句”或者“SQL片段”。但是这些SQL语句并不是直接传送给JDBC驱动的,而是 有着一个数据库方言层,经过方言层处理的SQL语句,就具备了在当前数据库上正确操作的能力。这相当于提供了一种能跨数据库操作的SQL语言。(E-SQL) E-SQL不但解决了异构数据库的语法问题、函数问题、特殊的写法问题,还解决了动态SQL问题、绑定变量扩展等特性。 对于各种常用SQL函数和运算符,都可以自动转换为当前数据库支持的方言来操作。其函数支持也要多于HQL支持的函数。 阅读推荐:第7、8章 特点三,可能是业界最快的ORM框架. 得益于ASM的动态代码生成技术,部分耗时操作通过动态代码固化为硬编码实现,EF-ORM的大部分操作性能要超过已知的其他框架。 实际性能测试明,EF的大部分操作都要快于Hiberante和MyBatis, 部分操作速度甚至数十倍于上述框架EF在极限插入模式下,甚至刷新了每秒10万条写入的记录。远远超过了其他框架。 一个初步的性能测试:测试代码:http://geequery.github.io/ef-orm/manual/performance-test.rar 测试报告:http://geequery.github.io/ef-orm/manual/performance-compare.docx 阅读推荐:第9、17章 特点四,分库分 开发过程中参照了Hibernate Shards、Alibaba TDDL、Cobar等框架,也是基于词法分析器来提取SQL参数,并计算路由。 能支持分库维度含糊等场景下的分库分。以及包括多库多下的 order by , distinct, group by, having等操作。 阅读推荐:第10章 特点五,常用DDL操作的封装 从数据库元数据访问,到建,创建约束,创建sequence等各种DDL操作进行了封装,用户无需编写各种SQL,可以直接通过API操作数据库结构。 尤其是ALTER TABLE等修改数据库的语句,各种不同的RDBMS都有较大语法差异。特点六、解决各种跨RDBMS的移植问题 1、DML操作、自增值处理与返回、查询这些不同数据库操作差异很大的东西,都了统一的封装。 2、DDL操作、建、删、trunacte,Sequence创建和TABLE模拟Sequence等,都做了支持。 3、对SQL语法操作和函数的改写与支持。其他特性轻量 该框架对应用环境、连接池、 是否为J2EE应用等没有特殊要求。可以和EJB集成,也可与Spring集成,也可以单独使用。整个框架只有两个JAR包,模块和功能都较为轻量。依赖少 整个框架只有三个jar库。间接依赖仅有commons-lang, slf4j等7个通用库,作为一个ORM框架,对第三方依赖极小。简单直接的API 框架的API设计直接面向数据库操作,不绕弯子,开发者只需要数据库基本知识,不必学习大量新的操作概念即可使用API完成各种DDL/DML操作。 最大限度利用编译器减少编码错误的可能性 API设计和元数据模型(meta-model)的使用,使得常规的数据库查询都可以直接通过Criteria API来完成,无需使用任何JPQL/HQL/SQL。可以让避免用户犯一些语法、拼写等错误。JPA2规范兼容 使用JPA 2.0规范的标准注解方式来定义和操作对象。(但整个ORM不是完整的JPA兼容实现)更高的性能 依赖于ASM等静态字节码技术而不是CGlib,使得改善了代理性能;依赖于动态反射框架,内部数据处理上的开销几乎可以忽略。操作性能接近JDBC水平。对比某H开头的框架,在写入操作上大约领先30%,在大量数据读取上领先50%以上。更多的性能调优手段 debug模式下提供了大量性能日志,帮您分析性能瓶颈所在。同时每个查询都可以针对batch、fetchSize、maxResult、缓存、级联操作类型等进行调整和开关,可以将性能调到最优。可在主流数据库之间任意切换 支持Oracle、MySQL、Postgres、MSSQL、GBase、SQLite、HSQL、Derby等数据库。除了API方式下的操作能兼容各个数据库之外,就连SQL的本地化查询也能使之兼容。JMX动态调节 可以用JMX查看框架运行统计。框架的debug开关和其他参数都可以使用JMX动态调整。动态支持 结构元数据的API也向用户开放,同时支持在使用过程中,灵活调整映射关系,因此用户可以用API动态的创建结构的模型,从而实现各种动态类型和的映射(例如POJO中包含一个Map,用于映射各种动态扩展的字段)企业级特性支持 SQL分析,性能统计,分库分,Oracle RAC支持,读写分离支持 标签:eform
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值