以前我做大項目中,我就提到要用entity framework 來做大項目的框架.可惜當時被否決了,由於當時自己對entity framework 也了解的並不是很深,所以當時也沒有力爭. 今年回到公司后,做了一個公司的小項目,就用的是entity framework. 因此也有時間好好研究該項目了.同時也做了大量的壓力測試,覺的大項目還是能用 entity framework的.
首先我們先說一個項目的框架,要考慮哪些因素.
1,易用性.這點很重要,作為一個框架,要能夠快速的寫出業務代碼出來,這樣才能幫助項目節省成本.
2.可擴展性和可維護性. 一個框架的改變雖然不多,但改變有時總是不可避免的.因為隨着需求的變化,用戶的訪問量增大.你會發現當初的框架會越來越不適合項目了.當達到一定程度的時候,就必須要下決心去優化架構了.
3.高性能. 一個好的框架,必須要能經得起性能的考驗.一個性能低下的框架,肯定會讓用戶無法接受的.當然,高性能和易用性可能存在一定的矛盾.關鍵是能找到平衡點.而且高性能也可以通過硬件的投入來解決.(后面章節,會介紹負載均衡的部署)
4.容易學習. 作為一個框架,一定要能讓項目成員快速學習.不要讓一個成員要一兩個星期,還只是勉強適應.這就是框架的失敗地方了.
5.迅速定位. 開發人員在開發中難免會犯一些這樣或那樣的錯誤.所以我們在開發底層框架中,要能做相應的檢查,並能做出有意義的錯誤提示,使得開發人員能快速定到問題所在.
因此這段時間,我也在好好研究相關的架構.首先找的是orm框架.因為根據我過去的各種項目經驗,覺的一個合適的orm框架,對於快速開發是一個多么重要的.如果沒有orm框架,我們就要花很多時間去寫相關的數據查詢工作.
目前Orm框架,.net普遍采用的有2種.一種是微軟的entity framework. 一種是由java那里引過來的nhibernate.我一開始,也對這2框架作了一下研究對比.雖然他們之間各有長處.但我覺的用 entity framework 應該更適合我們項目的開發.主要原因如下:
- Entity framework 用的是linq 查詢語言.這個相信很多.net 開發的人員都會.而nhibernate 用的是它自己的Hibernate Query Language (HQL).這個熟悉的人會比較少,雖然這些都可以快速學習.但是如果要精通,還是要時間的.
- entity framework 是微軟主推的.目前它的更新進度非常快.而且它也不斷推出新功能出來. 如entity framework 5 已對性能有了極大的提高. 具體可查看博客http://www.infoq.com/news/2012/02/EF-5. 而即將推出的entity framework 6.會實現異步查詢功能.
- Nhibernate 的使用比entity framew 復雜的多.當然,它 的復雜性,也有一定好處,帶來了更多的可擴展性. 但我我覺的這種東西是對於我們大部分項目來說,是缺點大於優點的.
有關entity framework 和 nhibernate 的區別可參看如下文章http://weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx
當然用entity framework 作為底層框架.它也存在一些問題.但隨着自己的研究,我也逐漸解決了這些問題.
- 是表太多,比如1,2百張表.這在大項目中相當普遍的.
對於這種現象,我們可以通過視圖的方式,把這些表發布在不同視圖.這樣就可以使我們的實體設計器,變的比較好看和容易維護.
2.是誇庫中,如何實現連接查詢.
對於一些大型項目,往往會分幾個業務庫.但這些業務庫往往會跟一個主庫有關聯關系.比如用戶表,部門表等人員基本信息.對於這種情況,我想的是把基本庫的一些主要信息緩存起來,然后用緩存的信息去跟業務庫進行關聯查詢.如要根據業務庫userId去主庫查人名.這個我們完全可以把業務庫數據查出來,然后再用userid去查緩存獲取人名.
3.是批量修改和刪除
目前Entity framework 沒有批量刪除和修改的方法,如果我們采用先批量查詢出來實體,然后再一個一個去做刪除或修改,這樣務必會造成生成一大堆的語句.肯定會嚴重影響效率的. 雖然我們可以通過直接組裝sql語句,或通過存儲過程來操作.但這畢竟是下策.其實我們可以擴展entity framework 來實現linq方式進行批量刪除和修改.(相關的方法,我將會在后續的章節介紹)
4.使用過程中發現很多地方性能不好.
其實這往往是由於開發人員不了解entity framework屬性造成的.寫的語句有問題.就好像一個不熟悉sql語句的人,寫出來的語句,性能會有很大的差別.就拿我優化過的一個業務方法,當時我同事寫的方法,一開始用壓力測試10個,都老報死鎖問題,而且平均時間要50多秒.后來我優化了.壓力測20個也是3,4秒鍾.(我們這個業務方法是比較復雜,有大量的數據插入和更改,我們是按實際環境中的用戶數來壓的).而且也很少報錯.
因此我覺的我們要解決這方面的問題,在進行entity framework 開發時,必須要進行一些培訓,由一些有經驗的同事進行講解,並形成文檔,以供大家參考.同時在開發中也要進行code review .隨時發現開發中的一些問題.這樣就可以確保我們項目的質量.(有關如何提高entity framework的性能的文章,我也會在以后發布)
這是我關於entity framework 的一些研究,當然畢竟我還沒有把entity framwwork用於大項目,這其中或許有其他問題. 但我相信車到山前必有路.只要大的方向沒錯,其他都好解決. 而且我始終相信,不管是ado.net, enterprise database, 還是entity framework 都是把生成的語句送到數據庫去查詢獲取數據. 只不過entity framework 多了一個把lingq 語句轉成sql ,需要一定的時間消耗,隨着微軟的推動,這方面的消耗已經越越少了.再說,解決這些性能問題,我們還可以增加硬件的投入來獲取,不一定要用花大量人員開發來獲取.畢竟人的成本比機器的會高很多.
接下來的章節,我會像大家介紹我做的對 entity framework 和ado.net的性能對比.到時我們會發現在一些情況下, entity framework 比ado.net的性能更好.