簡(jiǎn)介

之前寫個(gè)一個(gè)基于Dapper的分頁(yè)實(shí)現(xiàn)，現(xiàn)在再來(lái)寫一個(gè)基于Entity Framework的分頁(yè)實(shí)現(xiàn)，以及增刪改的通用實(shí)現(xiàn)。

代碼

還是先上代碼：https://github.com/jinweijie/EF.GenericRepository

如何運(yùn)行示例

還是像先前一樣：

1. 先Clone下代碼，在Database里面解壓縮Database.7z

2. Attach到Sql Server LocalDB上。如果你用的不是Sql Server的LocalDB，你需要更改App.Config里的連接字符串。

3. Ctrl + F5，運(yùn)行示例程序。

Repository 基類 - 查詢

Common\AbstractRepository.cs 是Repository的基類，實(shí)現(xiàn)了增刪改查的一些方法，例如：

public virtual Tuple<IEnumerable<T>, int> Find(Expression<Func<T, bool>> criteria
      , int pageIndex
      , int pageSize
      , string[] asc
      , string[] desc
      , params Expression<Func<T, object>>[] includeProperties)

這個(gè)方法是AbstractRepository查詢方法中的一個(gè)，用于自定義分頁(yè)查詢，其中criteria 為一個(gè)表達(dá)式，作為查詢的條件，參數(shù)pageIndex, pageSize, asc, desc為分頁(yè)相關(guān)參數(shù)；

關(guān)于多表（關(guān)聯(lián)表）：

includeProperties為在多表時(shí)候，Join相關(guān)聯(lián)的表。因?yàn)镋F默認(rèn)是Lazy Loading，相關(guān)聯(lián)的表默認(rèn)不是立即加載的，所以有時(shí)候如果寫代碼不小心，在for循環(huán)里就有可能會(huì)循環(huán)查詢n個(gè)字表。用來(lái)includeProperties參數(shù)，就可以在查詢時(shí)候join關(guān)聯(lián)表。

Repository 基類 - 增刪改

AbstractRepository已經(jīng)用泛型實(shí)現(xiàn)了增刪改方法：

public virtual T Create(T entity)
public virtual T Update(T entity)
public virtual T CreateOrUpdate(T entity)
public virtual void Delete(TId id)

另外，關(guān)于transaction的實(shí)現(xiàn)，我使用了Unit of Work模式，多個(gè)Repository共享一個(gè)DBContext，關(guān)于UOW，請(qǐng)?jiān)贑ommon\UnitOfWork.cs里找到。

調(diào)用UOW的時(shí)候，基本類似于這樣：

var uow = new EFUnitOfWork();
var repo = uow.GetLogRepository();

repo.Create(new Log
{
  LevelId = 1,
  Thread = "",
  Location = "Manual Creation",
  Message = "This is manually created log.",
  CreateTime = DateTimeOffset.Now,
  Date = DateTime.Now
});

uow.Commit();

從UnitOfWork里得到一個(gè)或多個(gè)Repository，共享DBContext，做增刪改操作，最后uow統(tǒng)一SaveChanges。

Repository的派生類

由于已經(jīng)有了AbstractRepository，實(shí)現(xiàn)了增刪改查的很多方法，所以派生類，例如示例項(xiàng)目里的LogRepository基本就可以變得很簡(jiǎn)單，主要實(shí)現(xiàn)一些特定的業(yè)務(wù)邏輯，在示例項(xiàng)目里，因?yàn)闆](méi)有特殊的業(yè)務(wù)邏輯，所以會(huì)很簡(jiǎn)單：

public class LogRepository : AbstractRepository<Log, int>
  {
    public LogRepository(EFContext context)
      : base(context)
    {
    }
  }

關(guān)于Entity的生成

本人比較喜歡Database First 實(shí)現(xiàn)，先設(shè)計(jì)數(shù)據(jù)庫(kù)，然后用edmx reverse engineering，生成POCO?？梢詤⒖糆ntity目錄下的相關(guān)文件。

當(dāng)然，如果你喜歡Code First，同樣沒(méi)有問(wèn)題，仍然適用本文的實(shí)現(xiàn)。

使用Logging日志追蹤EF SQL

在使用Entity Framework的時(shí)候，最好關(guān)心一下EF所生成的SQL，這樣可以在開發(fā)階段發(fā)現(xiàn)一些潛在的性能問(wèn)題，避免在生產(chǎn)環(huán)境焦頭爛額:)

在Common\EFContext.cs 里，有一個(gè)配置項(xiàng)EnableTraceSql，如果為true，那么所以EF生成的SQL將會(huì)被nlog記錄下來(lái)。我將nlog的日志配置到了數(shù)據(jù)庫(kù)。也就是說(shuō)，在你運(yùn)行示例項(xiàng)目時(shí)，每次查詢，都會(huì)增加新的日志記錄，內(nèi)容為查詢時(shí)生成的SQL：

Specification Pattern

在查詢方法里，有個(gè)重載是接受一個(gè)ISpecification示例，這樣的實(shí)現(xiàn)可以有效的控制業(yè)務(wù)邏輯，對(duì)于寫給被其他人調(diào)用的接口來(lái)說(shuō)，可以明確的確定查詢參數(shù)，例如：

public class LogSearchSpecification : ISpecification<Log>
  {
    public string LevelName { get; set; }
    public string Message { get; set; }
    public Expression<Func<Log, bool>> ToExpression()
    {
      return log => (log.Level.Name == LevelName || LevelName == "") &&
             (log.Message.Contains(Message) || Message == "");
    }

    public bool IsSatisfiedBy(Log entity)
    {
      return (entity.Level.Name == LevelName || LevelName == "") &&
          (entity.Message.Contains(Message) || Message == "");
    }
  }

那么，調(diào)用這個(gè)查詢方法的代碼就可以明確知道，我的查詢條件為L(zhǎng)evelName和Message，至于LevelName是等于以及Message為L(zhǎng)ike則是在LogSearchSpeficiation里實(shí)現(xiàn)，做到很好的封裝。

最后

這套實(shí)現(xiàn)是幾年來(lái)平時(shí)慢慢積累的，是經(jīng)過(guò)實(shí)踐的，所以應(yīng)該可以作為一定的參考，當(dāng)然，在具體的項(xiàng)目里，可以用一些DI去拿到Repository等等，不在本文討論范圍，大家可以自由發(fā)揮，希望對(duì)大家可以有所幫助，謝謝。

最新評(píng)論