tag:blogger.com,1999:blog-4500363753981919783.post5725866946975517405..comments2023-10-03T22:06:50.708+08:00Comments on Huan-Lin 學習筆記: Repository,我可能不會用你Michael Tsaihttp://www.blogger.com/profile/00364693770445538641noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-4500363753981919783.post-29843729787196688462014-10-13T20:06:37.151+08:002014-10-13T20:06:37.151+08:00抱歉打錯字,上面的 "MVC5+EF5" 應是 "MVC5+EF6&q...抱歉打錯字,上面的 "MVC5+EF5" 應是 "MVC5+EF6",Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-233518127840142892014-10-13T20:04:05.911+08:002014-10-13T20:04:05.911+08:00EF5 有 DbSet 耶。如果我沒理解錯,DbSet 應是從 EF 4.1 開始出現(DbCont...EF5 有 DbSet 耶。如果我沒理解錯,DbSet 應是從 EF 4.1 開始出現(DbContext 和 DbQuery 也是)。<br />MVC5+EF5 教學範例之所以略過 Repository,背後的原因或許只是單純因為想要簡化練習步驟,或者是因為 Repository 的相關文章到處都找得到,不需要再重複了。不過猜想畢竟只是猜想。實務上,還是依個別專案的實際需要來決定是否採用。我的看法是若沒有需要、沒有為專案帶來明顯的好處,就不要加上 Repository 層。Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-1859586703916677342014-10-13T17:10:38.045+08:002014-10-13T17:10:38.045+08:00我猜測MVC5+EF6抽掉Repository的原因,是因為先前EF5的版本需要Repository...我猜測MVC5+EF6抽掉Repository的原因,是因為先前EF5的版本需要Repository做切換測試,但是EF6有了DbSet,,所以不需要利用Reposity也可以直接在記憶體測試??Anonymoushttps://www.blogger.com/profile/04923951248563270397noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-45977559311503544062012-12-06T20:04:43.650+08:002012-12-06T20:04:43.650+08:00了解,Thanks :)了解,Thanks :)Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-66542203442182791792012-12-06T09:56:55.621+08:002012-12-06T09:56:55.621+08:00在設計上會是一個 IRepository 介面,然後有多種 Repository 實作。
這裡面了設...在設計上會是一個 IRepository 介面,然後有多種 Repository 實作。<br />這裡面了設計思路,是IRepository是為BLL服務,只提供BLL服務需要的功能。<br />以這樣的角度去思考,就能讓IRepository的設計範圍不發散。<br /><br />至於泛型Repository,我是比較少用到的設計,畢竟這樣的設計是以DAL層的角度來看待Repository。<br />通常會用的場合是在使用EF的場合下,EF已經幫忙建好提供CRUD的物件,<br />繼承這個物件並且讓這個物件實做IRepository,就能注入到BLL層,這樣是比較有可能會用到泛型Repository的情景。Clarkhttps://www.blogger.com/profile/13902532235164838469noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-15683196611606436982012-12-05T22:05:14.805+08:002012-12-05T22:05:14.805+08:00對於系統之外的各種資料來源....老實說這個部分我還有點疑問:是只定義一個 IRepository ...對於系統之外的各種資料來源....老實說這個部分我還有點疑問:是只定義一個 IRepository 介面,然後有多種 Repository 實作,還是每碰到一種一種資料來源,就會有不同的 Repository 介面?<br />也就是說,是將 DRY 原則發揮到極致(也許是採用泛型 Repository?),還是只是要讓程式撰寫模型盡量趨於一致,這部分我欠缺實務經驗,只憑空想像,覺得似乎是後者的成分居多。<br />還看過一種說法:如果是關聯式資料庫,就使用 ORM;如果是非關聯式資料庫,則針對那類資料來源實作一個 DAO。其基本理念是:尊重底層儲存體的結構。<br />寫得有點多了....這些原本打算整理到下一篇筆記的。不過還是很高興聽到各種實戰經驗分享,很難得的。Thanks!!Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-65530151421010563402012-12-05T21:42:55.816+08:002012-12-05T21:42:55.816+08:00嗯,Repository 作為隔離之用,合理。嗯,Repository 作為隔離之用,合理。Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-24852558465908077582012-12-05T09:19:26.139+08:002012-12-05T09:19:26.139+08:00Repository一開始的用意,的確只是隔離BLL與DAL,讓領域邏輯不相依DB。系統演進的過程中...Repository一開始的用意,的確只是隔離BLL與DAL,讓領域邏輯不相依DB。系統演進的過程中就會發現,Repository除了隔離DB、讓BLL層更加的凝聚之外,也封裝的資料來源這個概念。<br /><br />也就是說系統之外的資料來源,都可以用Repository去隔離。例如說:別人的系統、公司內部的子系統、硬體設備,這些都可以當作DAL層的來源。Clarkhttps://www.blogger.com/profile/13902532235164838469noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-47665933148713497302012-12-05T08:57:22.363+08:002012-12-05T08:57:22.363+08:00IT Player, 我昨天才從一位老朋友那裏聽到一件正在發生的事情:原本用得好好的 Oracle,...IT Player, 我昨天才從一位老朋友那裏聽到一件正在發生的事情:原本用得好好的 Oracle,客戶嫌她「太慢」,而開始慎重考慮把資料庫換成 Sybase。他們做的是專案,客戶說了算。或許真的世事難料,原本以為不可能替換的東西,還是有那麼一絲機率會發生 XD<br />至於把 Oracle 換成 Sybase 的原因是嫌 Oracle 太慢,這又是另一則故事(笑話)了 OrzMichael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-48999713376084899532012-12-03T10:11:23.090+08:002012-12-03T10:11:23.090+08:00作者已經移除這則留言。被軟體開發耽誤的廚工https://www.blogger.com/profile/00144958407872087293noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-29183304757857673672012-12-03T10:11:09.005+08:002012-12-03T10:11:09.005+08:00其實大多數所謂的要切換 persistence layer 的終極目標,大多只是為了 "要...其實大多數所謂的要切換 persistence layer 的終極目標,大多只是為了 "要能夠用讓系統配合不同的 RDBMS"。<br /><br />專案不太需要,產品才有可能。<br />只要搞清楚,persistence layer 的更換真正意義是什麼,要真的是換 RDBMS 的話。<br /><br />只要設計得宜,EF / NHibernate 這些東西甚至不需要出現。(有當然更好,節省開發時間)。被軟體開發耽誤的廚工https://www.blogger.com/profile/00144958407872087293noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-30041135834701939062012-12-03T08:24:21.390+08:002012-12-03T08:24:21.390+08:00嗯,了解。Thanks ^^
順便一提,為了平衡報導,我正在整理另一篇支持 Repository 的...嗯,了解。Thanks ^^<br />順便一提,為了平衡報導,我正在整理另一篇支持 Repository 的筆記。Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-74348156537416452842012-12-01T15:17:15.630+08:002012-12-01T15:17:15.630+08:00IUserRepository
-EFUserRepository
-SqlUserReposito...IUserRepository<br />-EFUserRepository<br />-SqlUserRepository<br />目前的專案都是採用上列這樣的命名規則,因為採用EFUserProvider少了代表邊界物件的語意。<br /><br />至於先前文章中會撰寫為UserRepositoryProvider這樣落落長的名稱,<br />是因為考量UserRepository中有時會封裝一些計算的功能,<br />為了跟DI進來的邊界物件作區隔,<br />所以額外加上了Provider尾字再隔離出去一層。<br /><br />但是現在回頭看,覺得自己有點畫蛇添足阿。XD<br />Clarkhttps://www.blogger.com/profile/13902532235164838469noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-45343475787911358972012-11-30T12:13:06.834+08:002012-11-30T12:13:06.834+08:00嗯,我想是的。只是有個小小疑問:EFUserRepositoryProvider 如果叫做 EFUs...嗯,我想是的。只是有個小小疑問:EFUserRepositoryProvider 如果叫做 EFUserProvider 會不會比較恰當?因為這些 XyzRepositoryProvider 類別都是提供 Xyz 物件,而不是提供特定實作的 Repository。<br />關於 Provider 的設計模式,也許改天我會再整理一篇筆記,不過目前腦袋還很混沌,想法還很模糊...隨緣吧 ^^Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-34234751578139299702012-11-30T11:55:00.817+08:002012-11-30T11:55:00.817+08:00採用ORM不牴觸的說,例如EFUserRepositoryProvider。:D
採用ORM不牴觸的說,例如EFUserRepositoryProvider。:D<br />Clarkhttps://www.blogger.com/profile/13902532235164838469noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-51878751209931882662012-11-30T08:15:30.759+08:002012-11-30T08:15:30.759+08:00感謝 Clark 的分享!
我發現你有一篇文章詳細說明了你在留言中提到的設計方式,還提供了範例程式,...感謝 Clark 的分享!<br />我發現你有一篇文章詳細說明了你在留言中提到的設計方式,還提供了範例程式,對於評估是否採用 Repository 也很有幫助,所以我將你的那篇文章加入本文的延伸閱讀清單了。<br />我的觀察是,BLL 裡面將會有一層薄薄的 Repository(例如 UserRepository、ProductRepoitory....等等),在 DAL 裡面對應的 Repository 類別才提供了對應的實作,例如你的範例中的 SqlUserRepositoryProvider。然後再透過相依性注入的方式將這兩層黏起來。 <br />如果實際專案的需求會要切換後端資料來源,這樣的設計我想是個不錯的選擇。如果沒有這樣的需求,而且已經決定採用 ORM 的情況下,就得斟酌是否值得引進這個抽象層,畢竟它會增加初期開發的 coding 成本,以及為應用程式加入不少類別(意味著複雜性也可能升高)。<br />Thanks :)Michael Tsaihttps://www.blogger.com/profile/00364693770445538641noreply@blogger.comtag:blogger.com,1999:blog-4500363753981919783.post-91151558842863019822012-11-30T00:53:41.269+08:002012-11-30T00:53:41.269+08:00Repository的設計概念,主要是做為領域層與資料對應層之間的媒介。
這個「媒介」的意思如果單純...Repository的設計概念,主要是做為領域層與資料對應層之間的媒介。<br />這個「媒介」的意思如果單純看做資料查詢的物件,在設計的時候會顯得綁手綁腳,因為很多功能都跟EF等等框架重疊了。<br /><br />但是換個角度把Repository看做一個IoC的實做,相依的方向是資料對應層相依領域層。<br />也就是說Repository是作為系統邊界的存在,而這個系統邊界是存在領域層與資料對應層之間。<br />套用Repository最主要的工作,讓整個領域層更加的凝聚。<br /><br />以這樣的角度去思考「泛型 Repository」、「aggregate root」就會發現,這些做法是以資料對應層的角度去實做,而不是以領域層的角度去設計。<br />基本上從本質就是有問題的設計,因為資料對應層的工作可以由EF、NHibernate來提供不需要Repository。<br />Repository應該只需要設計出領域層需要的介面就夠了。<br /><br />簡單說Repository的用意是隔離相依,讓領域層不相依任何其他的層,提高整個領域層的重用性、可測試性。 ^^Clarkhttps://www.blogger.com/profile/13902532235164838469noreply@blogger.com