none
使用DbContext是否还有必要引入Repository和UnitOfWork模式 RRS feed

  • 问题

  • 看到ado的博客上讲解了Repository和UnitOfWork模式,在使用的时候却发现DbContext类有这么一句提示

    我理解的DbContextt自己应该已经引入了这两个模式,不知道理解的有问题没有,

    http://www.cnblogs.com/mecity/archive/2011/07/17/2108508.html还是提到了可能需要引入Repository和UnitOfWork两个模式,不过看封装的代码似乎并没有省去多少代码,我理解引入Repository可能为了隐藏写入操作等。

    不知道各位认为是否用DbContext还需要再加入Repository模式,而且这个dbcontext是否有必要声明为全局单例,在wpf中的mvvm模式这个dbcontext需要加到那里,是在model中还是如果viewmodel需要也可以直接在viewmodel中用dbcontext查询呢?

    在下对于这种业务逻辑比较多的工程还是新手,如果有什么问题问的不合适,请谅解

    2012年5月26日 14:49

答案

  •  微软的NLayyerApp中在DbContext上封装了repository和unitofwork

    个人认为,DbContext确实实现了这两个模式,但是暴露出的DataSet太多,不符合防御式编程的思想。

    单独分离各个repository有利于业务逻辑的隔离,也使上层的接口不再依赖于EF这个底层的数据访问实现,有利于解耦

    2012年5月31日 2:39

全部回复

  • 想了一下不知道这边引入IRepository是否是为了解耦呢,如果是为了解耦那DbContext的介绍又是什么意思呢?
    2012年5月26日 15:00
  • 您好,有时候我们可能由于业务需要,在将修改后的信息提交到数据库之前对数据进行一些验证或者特殊处理,这个时候就可以在Repository中暴露出一个Save方法,将context.SaveChanges方法放入其中,并在调用该方法前根据业务需要对数据进行相应处理。


    Allen Li [MSFT]
    MSDN Community Support | Feedback to us

    2012年5月29日 5:03
    版主
  •  微软的NLayyerApp中在DbContext上封装了repository和unitofwork

    个人认为,DbContext确实实现了这两个模式,但是暴露出的DataSet太多,不符合防御式编程的思想。

    单独分离各个repository有利于业务逻辑的隔离,也使上层的接口不再依赖于EF这个底层的数据访问实现,有利于解耦

    2012年5月31日 2:39