tag:blogger.com,1999:blog-757034363076866663.post5768343538081924109..comments2023-07-19T18:59:57.943+08:00Comments on mrkt 的程式學習筆記: ASP.NET MVC 專案分層架構 Part.6 - DI/IoC 使用 Unity.MVCmrkt 的程式學習筆記http://www.blogger.com/profile/17962620480380791777noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-757034363076866663.post-35113750275934258412019-09-11T17:42:58.214+08:002019-09-11T17:42:58.214+08:00可以去查詢 Unit of Work可以去查詢 Unit of Workmrkt 的程式學習筆記https://www.blogger.com/profile/17962620480380791777noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-16403061178134985862019-09-11T12:42:28.644+08:002019-09-11T12:42:28.644+08:00請問,可以講講同一個action裡,如何在一個transaction做到 兩個不同service 的...請問,可以講講同一個action裡,如何在一個transaction做到 兩個不同service 的insert/update/delete?<br />類似 <br />using transaction<br />{ <br /> categoryService.Create(instance1);<br /> productService.Create(instance2);<br />}<br /><br />Anonymoushttps://www.blogger.com/profile/02125579024510412799noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-89186951151604961712018-09-06T19:11:51.067+08:002018-09-06T19:11:51.067+08:00網誌管理員已經移除這則留言。rmouniakhttps://www.blogger.com/profile/06622438005105687926noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-70715194103568729812017-11-01T18:39:37.135+08:002017-11-01T18:39:37.135+08:00抱歉,我看不懂問題的內容抱歉,我看不懂問題的內容mrkt 的程式學習筆記https://www.blogger.com/profile/17962620480380791777noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-88457327600680478412017-11-01T17:40:47.839+08:002017-11-01T17:40:47.839+08:00想問一問雖然 Class CategoryService.cs 中改以 CategoryServic...想問一問雖然 Class CategoryService.cs 中改以 CategoryService function 中以 IRepository parameter 以降低直接依賴, 但其實IRepository 當中的Generic Class Categories會對IRepository 限制, 其實Generic class 對 interface 是否增加耦合性?Anonymoushttps://www.blogger.com/profile/00436577205707961215noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-16535541385583093522017-07-22T00:58:19.915+08:002017-07-22T00:58:19.915+08:00現實總是殘酷,當你資歷是最菜的,3個都是前輩且還有資深都認為直接 Resolve 更方便時,
這些理...現實總是殘酷,當你資歷是最菜的,3個都是前輩且還有資深都認為直接 Resolve 更方便時,<br />這些理論還撼動不了他們的想法,我想只有等待技術債來臨或有權威的人才能改變作法,<br />此時的我能力不足,就算知道這更良好的做法,但總是被反駁,只能感謝大大幫我上了一堂課。Anonymoushttps://www.blogger.com/profile/05702363270645471840noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-87717106401201993462017-07-21T15:36:31.052+08:002017-07-21T15:36:31.052+08:00把類別依據職責去做設計時,一開始類別會用到哪些相依的類別就會制訂好,
指定好類別會有哪些屬性,建構式...把類別依據職責去做設計時,一開始類別會用到哪些相依的類別就會制訂好,<br />指定好類別會有哪些屬性,建構式就會一開始就指定好引數是要做哪些相依類別的注入<br />在實作方法的時候就不會超出職責太多<br /><br />然而一旦想要在原本設計好的類別裡去使用到原本沒有指定的相依類別時,<br />在合理的職責範圍裡,依據設計習慣,其實就是增加屬性,架構式增加引數<br />但其實不管是不是在合理的職責範圍裡,都是可以透過上面的作法去增加類別的相依類別<br />不過至少在後續維護的時候,在類別的建構式以及屬性就可以很快的看出該類別還有與哪些類別有相依<br /><br />如果大量的在方法裡直接去使用 Resolve 的方式,而不是透過類別一開始所制訂的屬性取得相依類別<br />無疑就是開了方便大門,不管是不是在職責裡的功能,反正就是用 Resolve 直接取得<br />長久下來,這個類別相依了多少類別就很難一眼看出,後續的維護就會很累<br />而且大量的使用 Resolve 方式,不就等於直接在方法裡去建立某類別的實體嗎(new Class1())<br />這樣就失去了使用 DI 的意義<br /><br />越來越多人直接開發 ASP.NET Core 專案,因為 asp.net core 一開始就提供了 DI,所以就會讓開發者要直接面對<br />在以往的 ASP.NET WebForm 與 ASP.NET MVC WebApi 專案,還是有很多開發者寫了多少年的程式卻連 DI 也沒用過<br />甚至連聽都沒聽過,也別說有這概念,既使有用過,但是很多都用偏了<br />所以就會有大量去直接使用 Resolve 的方式去偏廢了原本應該要用的建構式注入或屬性注入的作法<br />Resolve 方式不是不能夠用,而是需要正確的使用<br />mrkt 的程式學習筆記https://www.blogger.com/profile/17962620480380791777noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-80768885779656918492017-07-21T00:55:34.847+08:002017-07-21T00:55:34.847+08:00感謝大大回覆!
DI Fraemwork 目前是用 ASP.NET Core 內建的 DI,
類似 ...感謝大大回覆!<br />DI Fraemwork 目前是用 ASP.NET Core 內建的 DI,<br />類似 SL 功能的 Interface 我沒描述清楚,就是直接使用 DI 的 Resolve,<br />只是建立了一個 DI Interface ,實作內容就是使用內建 DI 的 Resolve,<br />然後應用上直接注入 DI Interface的實作到類別的建構子參數中,<br />之後方法裡直接使用該 DI Interface 的 Resolve 在需要的時候取得物件,<br />這種方式,讓我聯想到直接呼叫 SL 取得物件的功用類似感覺相同,<br />目前我覺得這方法除了懶惰可以少寫幾行代碼外,目前沒想到其他好處,<br />原本單元測試,我習慣在建構式就能看出所需要的哪些Interface,<br />現在因專案架構這樣做,單元測試額外就得多弄那個DI Interface,<br />但這些都不足影響資深前輩的想法,<br />大大回覆中提到『大量使用 Resolve 就容易破壞 SRP 單一職責,容易讓類別變成雜七雜八的超級類別』,<br />因為我沒直接使用 Resolve的後期經驗,很難搬出一個案例去跟專案資深前輩討論,<br />請問大大有這種案例參考嗎?Anonymoushttps://www.blogger.com/profile/05702363270645471840noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-15255205134068098662017-07-20T12:36:29.889+08:002017-07-20T12:36:29.889+08:00你所使用的 DI Framwork 是哪一個呢?而你所說的「類似 SL 的 Interface」是什...你所使用的 DI Framwork 是哪一個呢?而你所說的「類似 SL 的 Interface」是什麼呢?<br />我是覺得你應該將 Service Locator 的一些方法與 DI 的 Resolve 方法給混為一談了<br />應該是先理解你所使用的 DI Framework<br />一般而言,現在的開發者與開發的專案不會去直接使用到 Service Locator 才是<br /><br />回到 DI 的這部分來說,還是建議使用顯式的注入,例如建構式注入以及屬性注入,<br />而只有在無法使用建構式注入或屬性注入的情況下才會使用 DI 的 Resolve 方法去取得實作類別<br />大量的使用 Resolve 會有效能的問題,另一種就是因為「懶」或是貪圖方便,這會有之後維護上的問題,<br />類別使用相依型別,這是要好好考慮的,類別的設計應該要遵循 SOLID 原則<br />大量使用 Resolve 就容易破壞 SRP 單一職責,容易讓類別變成雜七雜八的超級類別(有人稱為上帝類別)<br />後續的維護就會是個大麻煩<br /><br />何謂 Service Locator pattern<br />http://www.cnblogs.com/gaochundong/archive/2013/04/12/service_locator_pattern.html<br /><br />P&P Unity 這套 DI Framework 所提供的 Resolve 方法<br />https://msdn.microsoft.com/en-us/library/ff664762(v=pandp.50).aspx<br />mrkt 的程式學習筆記https://www.blogger.com/profile/17962620480380791777noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-52537797461491498872017-07-20T00:08:26.268+08:002017-07-20T00:08:26.268+08:00你好,想請問 Dependency Injection(DI) 與 Service Location...你好,想請問 Dependency Injection(DI) 與 Service Location(SL) 應用的問題,<br />在工作上,由較資深的前輩定義專案架構,其中有使用了 DI 在建構式注入,<br />但資深前輩在建構式當中注入的是一個類似 SL 的 Interface,之後使用該 SL 物件取得服務物件,<br />說這樣就不用宣告一堆物件參數在建構式,某個 Method 想用的時候,就 SL.GetService(),<br />一開始跟著使用覺得好像也沒什麼問題,但我看見一篇文章<br />https://stackoverflow.com/questions/4985455/dependency-injection-vs-service-location<br />指出 DI + SL 同時使用是不建議,英文我沒能全理解,<br />故來詢問有經驗的前輩,這麼做是良好的作法,或者是隱藏著什麼問題?Anonymoushttps://www.blogger.com/profile/05702363270645471840noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-7181390079532793702013-08-15T11:22:39.174+08:002013-08-15T11:22:39.174+08:00有關這個部分的問題,我有找出原因,這也是當初我寫的時候沒有多加注意而衍生的一個錯誤,
因為 Regi...有關這個部分的問題,我有找出原因,這也是當初我寫的時候沒有多加注意而衍生的一個錯誤,<br />因為 RegisterTypes() 這個方法是 static 的,而在 ststic 裡去做建立一個 DbContext 實例的動作,<br />我這麼做就產生了問題,也就發生了你所說的狀況,這個我會在找個時間做個補充說明,<br />先簡短的說明一下,我們要做的修正就是把建立 DbContext 實例的步驟給移出 RegisterTypes() 靜態方法之外,<br />然後另外建立一個 IDbContextFactory 與 DbContextFactory,DbContextFactory 要做的事情就只有建立 DbContext 實例而已,<br />最後再到 RegisterTypes() 裡去增加註冊的步驟。<br /><br />最後也感謝你回應我這樣訊息。mrkt 的程式學習筆記https://www.blogger.com/profile/17962620480380791777noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-87413983466081675132013-08-15T11:02:05.765+08:002013-08-15T11:02:05.765+08:00謝謝回覆,了解。
那如果系統透過EF讀取資料,此時透過第三方修改資料時,有甚麼方式可以解決EF讀取先...謝謝回覆,了解。<br />那如果系統透過EF讀取資料,此時透過第三方修改資料時,有甚麼方式可以解決EF讀取先前資料的問題嗎?<br />我想到的只有每次去讀資料時,重新 new DbContext,重新抓資料。 = ="Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-90491667230905561202013-08-15T08:28:31.970+08:002013-08-15T08:28:31.970+08:00其實這個跟是否共用同一個 DbContext 沒有關係,既使是用最傳統的方式(沒有做分層,在每個 C...其實這個跟是否共用同一個 DbContext 沒有關係,既使是用最傳統的方式(沒有做分層,在每個 Controller 都各自建立 Entities)也是會有相同的狀況,這是因為 Entity Framework 在存取資料時會有一套機制,會暫存資料在系統中,當有透過 EF 進行資料變動時會去更新 DbContext 內的狀態,然後當有讀取資料的需求時就會先看 DbContext 有無讀取過該筆資料,如果有而且沒有修改過,就會直接把料給送出去。<br />而你所謂直接去修改資料庫中的資料,因為自己去修改資料,並不會通知 EF,所以就會出現取得的資料還是之前的狀況,跟是否用同一個 DbContext 無關。<br />mrkt 的程式學習筆記https://www.blogger.com/profile/17962620480380791777noreply@blogger.comtag:blogger.com,1999:blog-757034363076866663.post-23932431491193255032013-08-14T22:41:07.179+08:002013-08-14T22:41:07.179+08:00您好:
參考您的ASP.NET MVC 專案分層架構第一篇到的第六篇
也實作了相關程式。
遇到了一個...您好:<br />參考您的ASP.NET MVC 專案分層架構第一篇到的第六篇<br />也實作了相關程式。<br />遇到了一個問題。<br />此篇文章有提到:GenericRepository 建構式所需要傳入的 DbContext 就需要在 Unity 於建立類別實例的時就要給。<br />雖然新增/修改/刪除/查詢功能都正常,但我發現程式執行中時,如果直接去資料庫改資料,從Service讀出來的資料都還是舊的。應該是App_Start之後,都是共用同一個DbContext造成的。<br />不知道有什麽方式可以解決?Anonymousnoreply@blogger.com