注意:項目通過兩次搭建,因此截圖中頂級命名空間有ZHH和ZHH2區別,可是架構的內容是同樣的,能夠將ZHH和ZHH2視爲同一命名空間spring
一:權限管理數據庫
二:搜索服務器
|-Lucene.net(速度快)+盤古分詞(搜索詞拆分)---比模糊查詢更模糊session
|-模糊查詢like效率慢,全盤掃描,不能拆分架構
盤古分詞,分出來的詞,用文件存在磁盤內 ,文件併發 ----lock鎖->新的問題,效率慢,用戶須要等待併發
生產者消費者模式---優化文件併發框架
*sesion只能在一臺服務器存儲信息性能
-進程外數據庫中存session,性能差,沒人用測試
分佈式存儲Session數據
1-Memcached 內存操做,速度快.
2-分佈式文件(圖片)存儲
3.反向代理服務器:Nginx
4.WebService wcf
|-熱詞統計
三:工做流 WF
01IDao層
引用Model層,接口規範,查詢返回IQueryable<T>,延遲加載,調用纔會去生成查詢,優化性能
Expression--Lambda樹
查詢:
IQueryable<UserInfo> LoadEntities(Expression<Func<UserInfo,bool>>where);
分頁:
IQueryable<UserInfo> LoadPageEntities<Tkey>(int pageIndex, int pageSIze, out int totalCount, Expression<Func<UserInfo, bool>> where, Expression<Func<UserInfo, Tkey>> orderBy);
增:
UserInfo AddEntity(UserInfo entity);
刪:
bool DeleteEntity(UserInfo entity);
改:
bool UpdateEntity(UserInfo entity);
因爲每個接口,都須要定義CURD,那麼形成重複,so,封裝Base接口
繼承基接口
對外提供會話接口IDBSession
02Dao層
引用IDao層和Model層,Dao實現IDao中的接口規範,由於涉及具體數據庫操做,so,引用EF組件
Dao層引用EntityFramework組件
引起問題:再一次請求內不能屢次建立上下文實例
單例雖然能夠解決,可是新的問題
,當前應用程序全部的用戶都用同一個對象,而且追加數據操做到上下文對象中,會致使內存佔用愈來愈大,難以釋放
每次請求建立一個EF上下文實例,(線程內惟一)
當請求結束釋放
HttpContext 是一個線程內惟一對象
在Dao層定義DBContextFactory.cs(定義在Dao層,防止循環引用)上下文工廠
以上專業寫法
CallContext是HttpContext.Items內部對象(線程內惟一)
因爲全部的DAO都實現了CRUD,so,封裝一個基類BaseDao.cs,並使用上下文工廠類建立對象
重點是DbSet<T>的使用
Dao層子類繼承超類,並實現IUserInfoDao接口
DAO和BLL直接須要通訊,so,新建一個會話層(工廠),目的是解耦合
定義一個利用反射的抽象工廠DAOAbsFactory.cs反射
在Bll層中調用工廠類,以接口類型返回dao層的實例,下降Bll層和Dao層耦合度
抽象工廠類----數據會話層
抽象工廠(反射) 業務層與數據訪問層解耦
-只須要改配置文件,就能夠切換dao層
抽象工廠引用程序集
建立會話類實現Idao中的會話接口
有了會話層以後,新建一個會話工廠(內部涉及到EF操做,線程內惟一)
DBSessionFactory.cs
03IBLL
引用
封裝IBLL層接口超類
子接口繼承
04BLL
引用
子類
05WebApp
引用
MVC(測試略)