tag:blogger.com,1999:blog-757034363076866663.post6738610107889734357..comments2023-07-19T18:59:57.943+08:00Comments on mrkt 的程式學習筆記: ASP.NET MVC 專案分層架構 - 建議與補充說明mrkt 的程式學習筆記http://www.blogger.com/profile/17962620480380791777noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-757034363076866663.post-75071575896908093352019-05-17T16:34:37.205+08:002019-05-17T16:34:37.205+08:00Learn a lot!! Thanks!Learn a lot!! Thanks!Jasshttps://www.blogger.com/profile/05059580587636654890noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-71658361619428459622015-07-07T23:32:01.055+08:002015-07-07T23:32:01.055+08:00看起來你應該沒有做單元測試,
不管有沒有做單元測試,要不要使用 Repository 以及架構如何劃...看起來你應該沒有做單元測試,<br />不管有沒有做單元測試,要不要使用 Repository 以及架構如何劃分,其實就看實務需求來決定,<br />在大型企業或是喘統產業裡,要能夠使用 ORM 的機會不多,除非是新專案而且沒有包袱,<br />否則資料存取層還是會有,至於叫什麼名字都不打緊,主要就是資料存取的工作,<br />這一層也不見得會有抽換資料庫或是其他資料存取方式的需求,<br />但有了這一層,在大型架構以及要求嚴謹的軟體開發,做單元測試或是整合測試時,就會需要 Repository 的存在,<br />品質要求是相當重要的。mrkt 的程式學習筆記https://www.blogger.com/profile/17962620480380791777noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-27746205530719351192015-07-07T17:08:34.215+08:002015-07-07T17:08:34.215+08:00我在實作多層架構時,總是覺得Repository層有點多餘。
因為使用ORM(entity fram...我在實作多層架構時,總是覺得Repository層有點多餘。<br />因為使用ORM(entity framework),其實已經把實際的資料存取與邏輯隔離開來了。<br />就算需要換資料庫類型,只要Provider有提供,也都能抽換。<br />所以我後來做專案,都是保留Service層,但省略Repository層。<br />專案還是分為 Repository <- Service,但Repository只放了Context與Model等Entity物件,<br />實際上比較像是 Models <- BLL 這樣的感覺。<br /><br />不過有個專案,客戶有個很奇怪的要求(而且還是開發途中才說...)<br />「我們不懂ORM,要在專案裡面看到所有SQL Statement,否則就退」<br />已經用ORM做到幾乎收尾部份了...<br /><br />這時Repository這層的價值就出來了,<br />雖然很困擾,不過還是用SQL Statement去塞滿了Repository這層,等於自己實作了部分的ORM,<br />說真的算是規模很大的refactoring,但還好專案的其他部分(尤其是前端)不用跟著修改。<br />不過這個專案算是特例。Litfalhttps://www.blogger.com/profile/11495044865533366941noreply@blogger.com