Entity Framework 实体框架的形成之旅--利用Unity对象依赖注入优化实体框架(2)

在本系列的第一篇随笔《Entity Framework 实体框架的形成之旅--基于泛型的仓储模式的实体框架(1)》中介绍了Entity Framework 实体框架的一些基础知识,以及构建了一个简单的基于泛型的仓储模式的框架,例子也呈现了一个实体框架应用的雏形,本篇继续介绍这个主题,继续深化介绍Entity Framework 实体框架的知识,以及持续优化这个仓储模式的实体框架,主要介绍业务逻辑层的构建,以及利用Unity和反射进行动态的对象注册。

1、EDMX文件位置的调整

我们从上篇例子,可以看到这个随笔介绍的仓储模式的实体框架结构如下所示。

但实际上上篇随笔的例子是有点理想化的了,因为我们知道,【ADO.NET实体数据模型】生成的EDMX文件实质上自动生成了数据访问的上下文SqlserverContext,以及几个表的实体类,具体的效果如下所示。

我们理想化的把它放到DAL目录,Entity目录下,实际上是不可以的,至少是有冲突的。

那么我们应该如何处理,才能比较合理的处理这些自动生成的内容呢?另外我们已经把它上升了一层到业务层,具体的BLL分层如何处理数据访问对象的呢,通过什么方式构建数据访问对象?带着这些问题,我们再来一步步分析这个框架的内容。

为了给实体类友好的名称,我们顺便把表名的前缀移除了,如EDMX的图形如下所示。

为了比较好的利用EDMX文件的代码生成,我们把这个文件整体性的移动到了Entity目录下,如下所示。

这样相当于把数据访问的上下文,以及实体类的代码全部移动到Entity命名空间里面去了,虽然可能感觉不太好,但是我们先让它跑起来,具体的细节后面在优化完善。

2、业务逻辑层的设计

我们再来关注下业务逻辑层(包括业务逻辑接口层),和数据访问层类似,我们把它构建如下所示。

1)业务逻辑接口层

    /// <summary>
    /// 业务逻辑层基类接口
    /// </summary>
    /// <typeparam name="T">实体对象类型</typeparam>
    public interface IBaseBLL<T> where T : class
    {
        T Get(object id);

        IList<T> GetAll(Expression<Func<T, bool>> whereCondition);

        IList<T> GetAll();
    }

2)业务逻辑层实现

    /// <summary>
    /// 业务逻辑基类
    /// </summary>
    /// <typeparam name="T">实体对象类型</typeparam>
    public abstract class BaseBLL<T>: IBaseBLL<T>  where T : class
    {
        protected IBaseDAL<T> baseDAL { get; set; }

        public BaseBLL(IBaseDAL<T> dal)
        {
            this.baseDAL = dal;
        }

        public T Get(object id)
        {
            return baseDAL.Get(id);
        }

        public IList<T> GetAll(Expression<Func<T, bool>> whereCondition)
        {
            return baseDAL.GetAll(whereCondition);
        }

        public IList<T> GetAll()
        {
            return baseDAL.GetAll();
        }
    }

3)业务对象类的逻辑接口层

    /// <summary>
    /// 城市的业务对象接口
    /// </summary>
    public interface ICityBLL : IBaseBLL<City>
    {
    }

4)业务对象的逻辑层实现

    /// <summary>
    /// 城市的业务对象
    /// </summary>
    public class CityBLL : BaseBLL<City>
    {
        protected ICityDAL dal;

        public CityBLL(ICityDAL dal) : base(dal)
        {
            this.dal = dal;
        }
    }

上面基本上完整的阐述了业务逻辑层的实现了,不过我们看到一个问题,就是不管是逻辑层基类,还是具体业务对象的逻辑对象,都没有默认构造函数,我们不能使用new进行对象的创建!

这是一个严重的问题,那么我们如何才能规避这个问题,能够使我们的业务对象类能够使用默认函数,使用new创建对象呢?这里我们需要引入IOC容器做法,也就是使用微软的Unity进行对象的注入及使用。

3、使用Unity实现对象的依赖注入

1)Unity的简单介绍

Unity是Unity是微软patterns& practices组用C#实现的轻量级,可扩展的依赖注入容器,它为方便开发者建立松散耦合的应用程序,

有以下优点:

1.简化了对象的创建,特别是针对分层对象结构和依赖关系;

   2.需求的抽象,允许开发人员在运行时或配置文件中指定依赖关系,简化横切关注点的管理;

   3.推迟为容器配置组件的时机,增加了灵活性;

   4.服务定位能力,这使客户能够存储或缓存容器;

5.实例和类型拦截

Unity的依赖注入使用例子比较容易理解,具体代码如下所示。

 static void Main( string[] args )
 {
            //实例化一个控制器
            IUnityContainer unityContainer = new UnityContainer();

            //实现对象注入
            unityContainer.RegisterType<IBird, Swallow>();
            IBird bird = unityContainer.Resolve<IBird>();

            bird.Say();
}

这个Unity的对象,我们可以通过Nuget进行添加即可,添加后,在项目里面就有对应对应的程序集引用了。

2)引入Unity实现数据访问对象注入,完善逻辑层实现

了解了Unity的使用,我们可以在BaseBLL对象基类类里面构建一个IOC的容器,并在这个容器初始化的时候,注册对应的数据访问层对象即可,如下所示。

    /// <summary>
    /// 业务逻辑基类
    /// </summary>
    /// <typeparam name="T">实体对象类型</typeparam>
    public abstract class BaseBLL<T>: IBaseBLL<T>  where T : class
    {
        private static readonly object syncRoot = new Object();

        protected IBaseDAL<T> baseDAL { get; set; }
        protected IUnityContainer container { get; set; }

        /// <summary>
        /// 默认构造函数。
        /// 默认获取缓存的容器,如果没有则创建容器,并注册所需的接口实现。
        /// </summary>
        public BaseBLL()
        {
            lock (syncRoot)
            {
                container = DALFactory.Instance.Container;
                if (container == null)
                {
                    throw new ArgumentNullException("container", "container没有初始化");
                }
            }
        }

好,默认在DALFactory的类里面,我们就是在其实例化的时候,把需要的数据访问对象压进去,这样我们就可以在具体的业务对象逻辑类里面实现调用,如下代码所示。

    /// <summary>
    /// 城市的业务对象
    /// </summary>
    public class CityBLL : BaseBLL<City>
    {
        protected ICityDAL dal;

        public CityBLL()
        {
            dal = container.Resolve<ICityDAL>();
            baseDAL = dal;
        }

        public CityBLL(ICityDAL dal) : base(dal)
        {
            this.dal = dal;
        }
    }

如果我们不关心DALFactory里面的构架细节,这个框架已经完成的对象的注入,可以正常使用了。

但是我们还是来看看它的实现细节,我们通过单例模式(饿汉模式)构架IOC容器并注入相应的DAL对象了。

    /// <summary>
    /// 实体框架的数据访问层接口的构造工厂。
    /// </summary>
    public class DALFactory
    {
        //普通局部变量
        private static Hashtable objCache = new Hashtable();
        private static object syncRoot = new Object();
        private static DALFactory m_Instance = null;

        /// <summary>
        /// IOC的容器,可调用来获取对应接口实例。
        /// </summary>
        public IUnityContainer Container { get; set; }

        /// <summary>
        /// 创建或者从缓存中获取对应业务类的实例
        /// </summary>
        public static DALFactory Instance
        {
            get
            {
                if (m_Instance == null)
                {
                    lock (syncRoot)
                    {
                        if (m_Instance == null)
                        {
                            m_Instance = new DALFactory();
                            //初始化相关的注册接口
                            m_Instance.Container = new UnityContainer();

                            //手工加载
                            m_Instance.Container.RegisterType<ICityDAL, CityDAL>();
                            m_Instance.Container.RegisterType<IProvinceDAL, ProvinceDAL>();
                        }
                    }
                }
                return m_Instance;
            }
        }

OK,通过上面的Unity,我们实现了对象的注入及使用个,具体的窗体调用代码如下所示。

        private void btnCity_Click(object sender, EventArgs e)
        {
            DateTime dt = DateTime.Now;

            CityBLL bll = new CityBLL();
            var list = bll.GetAll();
            this.dataGridView1.DataSource = list;

            Console.WriteLine("花费时间:{0}", DateTime.Now.Subtract(dt).TotalMilliseconds);
        }

        private void txtCityName_KeyUp(object sender, KeyEventArgs e)
        {
            DateTime dt = DateTime.Now;
            CityBLL bll = new CityBLL();
            if(this.txtCityName.Text.Trim().Length > 0)
            {
                var list = bll.GetAll(s => s.CityName.Contains(this.txtCityName.Text));
                this.dataGridView1.DataSource = list;
            }
            else
            {
                var list = bll.GetAll();
                this.dataGridView1.DataSource = list;
            }
            Console.WriteLine("花费时间:{0}", DateTime.Now.Subtract(dt).TotalMilliseconds);
        }

我们可以得到具体的界面效果如下所示。

4、使用反射操作,在Unity容器动态注册接口对象

在上面的例子里面,不知道您是否注意到了,我们使用Unity的IOC容器的时候,注册的对象是指定的几个数据访问类。

     m_Instance.Container.RegisterType<ICityDAL, CityDAL>();
     m_Instance.Container.RegisterType<IProvinceDAL, ProvinceDAL>();

但这种有点类似硬编码的方式,在我们项目如果有大量的这些数据访问类,需要手工添加的话,那真不是一件雅观的事情。

如果代码能够根据接口和接口实现类,自动把我们所需要的接口对象注册进去,那该是多好的啊,可是能做到吗?能!

如果我们是在同一个程序集里面执行的话,那么我们通过反射操作,就可以从这个程序集里面获取对应的接口层(IDAL)和接口实现层(DAL)的对象,那么我们匹配它进行对象注入就可以了吧。

下面是我动态注册DAL对象的实现代码,如下所示。

        /// <summary>
        /// 使用Unity自动加载对应的IDAL接口的实现(DAL层)
        /// </summary>
        /// <param name="container"></param>
        private static void RegisterDAL(IUnityContainer container)
        {
            Dictionary<string, Type> dictInterface = new Dictionary<string, Type>();
            Dictionary<string, Type> dictDAL = new Dictionary<string, Type>();
            Assembly currentAssembly = Assembly.GetExecutingAssembly();
            string dalSuffix = ".DAL";
            string interfaceSuffix = ".IDAL";

            //对比程序集里面的接口和具体的接口实现类,把它们分别放到不同的字典集合里
            foreach (Type objType in currentAssembly.GetTypes())
            {
                string defaultNamespace = objType.Namespace;
                if (objType.IsInterface && defaultNamespace.EndsWith(interfaceSuffix))
                {
                    if (!dictInterface.ContainsKey(objType.FullName))
                    {
                        dictInterface.Add(objType.FullName, objType);
                    }
                }
                else if (defaultNamespace.EndsWith(dalSuffix))
                {
                    if (!dictDAL.ContainsKey(objType.FullName))
                    {
                        dictDAL.Add(objType.FullName, objType);
                    }
                }
            }

            //根据注册的接口和接口实现集合,使用IOC容器进行注册
            foreach (string key in dictInterface.Keys)
            {
                Type interfaceType = dictInterface[key];
                foreach (string dalKey in dictDAL.Keys)
                {
                    Type dalType = dictDAL[dalKey];
                    if (interfaceType.IsAssignableFrom(dalType))//判断DAL是否实现了某接口
                    {
                        container.RegisterType(interfaceType, dalType);
                    }
                }
            }
        }

有了这个利用反射动态注入对象的操作,我们在基类里面的实现就避免了硬编码的不便。

    /// <summary>
    /// 实体框架的数据访问层接口的构造工厂。
    /// </summary>
    public class DALFactory
    {
        //普通局部变量
        private static Hashtable objCache = new Hashtable();
        private static object syncRoot = new Object();
        private static DALFactory m_Instance = null;

        /// <summary>
        /// IOC的容器,可调用来获取对应接口实例。
        /// </summary>
        public IUnityContainer Container { get; set; }

        /// <summary>
        /// 创建或者从缓存中获取对应业务类的实例
        /// </summary>
        public static DALFactory Instance
        {
            get
            {
                if (m_Instance == null)
                {
                    lock (syncRoot)
                    {
                        if (m_Instance == null)
                        {
                            m_Instance = new DALFactory();
                            //初始化相关的注册接口
                            m_Instance.Container = new UnityContainer();

                            //根据约定规则自动注册DAL
                            RegisterDAL(m_Instance.Container);

                            //手工加载
                            //m_Instance.Container.RegisterType<ICityDAL, CityDAL>();
                            //m_Instance.Container.RegisterType<IProvinceDAL, ProvinceDAL>();
                        }
                    }
                }
                return m_Instance;
            }
        }

上面整个框架的优化过程,都是围绕着业务逻辑层进行的,最后我们实现了较好的动态对象的依赖注入,并给业务逻辑层对象提供了默认构造函数,让他们可以从IOC容器里面获取对象并创建。

但是我们看到,对于EDMX文件,我们只是把它放入了Entity的模块里面,也没有真正的对它如何处理,如果每次都需要使用这个edmx的文件生成操作,我依旧觉得开发效率比较低下,而且如果对于需要支持多个数据库如何处理呢?不可能在创建一个数据操作上下文吧,它们可以已经抽象化了,本身好像不是和具体数据库相关的,和数据库相关的只是它的配置关系而已啊。

这些问题留给下一篇继续对框架的演化处理吧,谢谢大家耐心的阅读,如果觉得有用,请继续推荐支持下,毕竟为了准备这个系列,我已经花了好多天的时间,从各个方面持续优化整个仓储模式的实体框架,留下一个个版本的Demo来整理博客的。

时间: 2024-10-12 13:37:46

Entity Framework 实体框架的形成之旅--利用Unity对象依赖注入优化实体框架(2)的相关文章

《Entity Framework 6 Recipes》中文翻译系列 (28) ------ 第五章 加载实体和导航属性之测试实体是否加载与显式加载关联实体

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-11  测试实体引用或实体集合是否加载 问题 你想测试关联实体或实体集合是否已经加载到上下文中,另外你想使用Code-First来管理数据访问. 解决方案 假设你有如图5-26所示的概念模型 图5-26 一个包含projects,managers和contractors的模型 在Visual Studio中添加一个名为Recipe11的控制台应用,并确保引用了实体框架6的库,NuGet可

DI 依赖注入之StructureMap框架

DI  依赖注入之StructureMap框架 一.简叙: structureMap只是DI框架中的其中之一. 二.安装: 三.使用: 原文地址:https://www.cnblogs.com/zlp520/p/9094730.html

《Entity Framework 6 Recipes》中文翻译系列 (23) -----第五章 加载实体和导航属性之预先加载与Find()方法

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-2  预先加载关联实体 问题 你想在一次数据交互中加载一个实体和与它相关联实体. 解决方案 假设你有如图5-2所示的模型. 图5-2 包含Customer和与它相关联信息的实体 和5-1节一样,在模型中,有一个Customer实体,一个与它关联的CustomerType和多个与它关联的CustomerEamil.它与CustomerType的关系是一对多关系,这是一个实体引用(译注:Cu

《Entity Framework 6 Recipes》中文翻译系列 (26) ------ 第五章 加载实体和导航属性之延缓加载关联实体和在别的LINQ查询操作中使用Include()方法

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-7  在别的LINQ查询操作中使用Include()方法 问题 你有一个LINQ查询,使用了类似这样的操作 group by,join,和where:你想使用Include()方法预先加载额外的实体.另外你想使用Code-First来管理数据访问. 解决方案 假设你有如图5-22所示的概念模型 图5-22 一个简单的包含Club和Event以及它们之间一对多关联的模型 在Visual S

《Entity Framework 6 Recipes》中文翻译系列 (25) ------ 第五章 加载实体和导航属性之加载完整的对象图和派生类型上的导航属性

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-5  加载完整的对象图 问题 你有一个包含许多关联实体的模型,你想在一次查询中,加载完整的对象图实例.一般地,当一个页面视图需要呈现关联实体集时,你会选择这种方法,而不是延迟加载,因为延迟加载是通过一系列的短小查询来获取关联实体的. 解决方案 假设你有如图5-20所示的概念模型.每门课程有很多节,每一节由一个老师教多名学习. 图5-20 一个包含许多关联实体的模型 使用Include()

《Entity Framework 6 Recipes》中文翻译系列 (29) ------ 第五章 加载实体和导航属性之过滤预先加载的实体集合和修改外键关联

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-13  过滤预先加载的实体集合 问题 你想过滤预先加载的实体集合,另外,你想使用Code-First来管理数据访问 解决方案 实体框架不支持直接使用Include()时过滤关联实体集合,但我们可以通过创建一个匿名类型来完成同样的事情,匿名类型包含实体和要过滤的关联实体集合. 假设你有如图5-28所示的概念模型 图5-28 一个包含movies(电影)和它的categories(目录)的模

《Entity Framework 6 Recipes》中文翻译系列 (22) -----第五章 加载实体和导航属性之延迟加载

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 第五章 加载实体和导航属性 实体框架提供了非常棒的建模环境,它允许开发人员可视化地使用映射到数据库中的表.视图.存储过程以及关系中的实体类型.本节将向你展示如何控制查询操作中的关联实体的加载. 实体框架的默认行为是只加载应用程序直接需要的实体.通常情况下,这正是你需要的.如果实体框架通过一个或多个关联积极地加载关联实体,最终,你很有可能得到超过你需求的实体.这不但增加了内存占用,而且还影响了

《Entity Framework 6 Recipes》中文翻译系列 (27) ------ 第五章 加载实体和导航属性之关联实体过滤、排序、执行聚合操作

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-9  关联实体过滤和排序 问题 你有一实体的实例,你想加载应用了过滤和排序的相关实体. 解决方案 假设你有如图5-24所示的概念模型 图5-24 一个酒店预定系统的模型 假设我们有一个酒店(Hotel)实体,使用代码清单5-22,获取酒店的商务套房(executive suite),查看是否被预定,并按房价排序. 代码清单5-22.通过方法Entry()和Query()显式加载实体集合,

Entity Framework 6 Recipes 2nd Edition(12-5)译 -&gt; 自动删除相关联实体

12-5. 自动删除相关联实体 问题 当一个实体被删除时,你想自动删除它相关联的实体 解决方案 假设你有一个表结构由一个course (科目), course 的classes (课程),以及enrollment (登记学生选课),如 Figure 12-5所示:. Figure 12-5. The Course, Class, and Enrollment tables in our database 由上述表生成一个模型,如下图Figure 12-6所示:. Figure 12-6. A m