簡介
之前寫個一個基于Dapper的分頁實現(xiàn)，現(xiàn)在再來寫一個基于Entity Framework的分頁實現(xiàn)，以及增刪改的通用實現(xiàn)。
代碼
還是先上代碼：https://github.com/jinweijie/EF.GenericRepository
如何運行示例
還是像先前一樣：
1. 先Clone下代碼，在Database里面解壓縮Database.7z
2. Attach到Sql Server LocalDB上。如果你用的不是Sql Server的LocalDB，你需要更改App.Config里的連接字符串。
3. Ctrl + F5，運行示例程序。
Repository 基類 - 查詢
Common\AbstractRepository.cs 是Repository的基類，實現(xiàn)了增刪改查的一些方法，例如：
|
1
2
3
4
5
6
|
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) |
這個方法是AbstractRepository查詢方法中的一個，用于自定義分頁查詢，其中criteria 為一個表達式，作為查詢的條件，參數(shù)pageIndex, pageSize, asc, desc為分頁相關參數(shù)；
關于多表（關聯(lián)表）：
includeProperties為在多表時候，Join相關聯(lián)的表。因為EF默認是Lazy Loading，相關聯(lián)的表默認不是立即加載的，所以有時候如果寫代碼不小心，在for循環(huán)里就有可能會循環(huán)查詢n個字表。用來includeProperties參數(shù)，就可以在查詢時候join關聯(lián)表。
Repository 基類 - 增刪改
AbstractRepository已經(jīng)用泛型實現(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)
另外，關于transaction的實現(xiàn)，我使用了Unit of Work模式，多個Repository共享一個DBContext，關于UOW，請在Common\UnitOfWork.cs里找到。
調(diào)用UOW的時候，基本類似于這樣：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
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里得到一個或多個Repository，共享DBContext，做增刪改操作，最后uow統(tǒng)一SaveChanges。
Repository的派生類
由于已經(jīng)有了AbstractRepository，實現(xiàn)了增刪改查的很多方法，所以派生類，例如示例項目里的LogRepository基本就可以變得很簡單，主要實現(xiàn)一些特定的業(yè)務邏輯，在示例項目里，因為沒有特殊的業(yè)務邏輯，所以會很簡單：
|
1
2
3
4
5
6
7
|
public class LogRepository : AbstractRepository<Log, int> { public LogRepository(EFContext context) : base(context) { } } |
關于Entity的生成
本人比較喜歡Database First 實現(xiàn)，先設計數(shù)據(jù)庫，然后用edmx reverse engineering，生成POCO。可以參考Entity目錄下的相關文件。
當然，如果你喜歡Code First，同樣沒有問題，仍然適用本文的實現(xiàn)。
使用Logging日志追蹤EF SQL
在使用Entity Framework的時候，最好關心一下EF所生成的SQL，這樣可以在開發(fā)階段發(fā)現(xiàn)一些潛在的性能問題，避免在生產(chǎn)環(huán)境焦頭爛額:)
在Common\EFContext.cs 里，有一個配置項EnableTraceSql，如果為true，那么所以EF生成的SQL將會被nlog記錄下來。我將nlog的日志配置到了數(shù)據(jù)庫。也就是說，在你運行示例項目時，每次查詢，都會增加新的日志記錄，內(nèi)容為查詢時生成的SQL：
Specification Pattern
在查詢方法里，有個重載是接受一個ISpecification示例，這樣的實現(xiàn)可以有效的控制業(yè)務邏輯，對于寫給被其他人調(diào)用的接口來說，可以明確的確定查詢參數(shù)，例如：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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)用這個查詢方法的代碼就可以明確知道，我的查詢條件為LevelName和Message，至于LevelName是等于以及Message為Like則是在LogSearchSpeficiation里實現(xiàn)，做到很好的封裝。
最后
這套實現(xiàn)是幾年來平時慢慢積累的，是經(jīng)過實踐的，所以應該可以作為一定的參考，當然，在具體的項目里，可以用一些DI去拿到Repository等等，不在本文討論范圍，大家可以自由發(fā)揮，希望對大家可以有所幫助，謝謝。
