【第二十五天】要使用Repository嗎？

其實就我本人而言，我一直認為Repository用起來很雞肋，因為複雜的關聯模型共用的機會很少，那麼直接把這不會共用到的Query寫在Service裡面好像也沒有什麼不好，如果真的複雜到可能會timeout的情況，可能也會另外建立SQL view。

參考Repository到底是啥？

• 文件一
• 文件二
• 套件一

說了這麼多那總是會有共用的吧！
例如：會員的資料表內可能隱藏各種永遠不會顯示給前端畫面看見的資訊，串其它金流服務的辨識 id、關聯到一些外部無法自己控制的 token之類的，這些資訊又和會員的姓名生日血型混在一起的時候咧？
如果每次都從 Model拿顯示給前端的基本資料，還要選欄位就太不帥了！
不過直接從 Model取出來之後拿自己要的東西回傳不也可以嗎？好吧！那放進 Repository裡面。
但明天又多出另一個需求是要寄一些會員通知信，只需要取得會員的姓、性別、信箱，那麼用上面 Repository裡做出的取基本資料 Method再去做欄位的 Filter嗎？但這 Filter不就又是寫在 Service了嗎？還是在 Transformer時直接拿取要的內容就行了呢？繞了一圈回來怎麼又還是在上面呢？
還是要取一個經典的例子，取出帳號啟用且年齡大於20歲以上有經濟能力的會員呢？那如果之後又發現35-55歲為主力客群，要取他們的資料呢？
命名又該如何？getUserAgeWhere20UP、getUserTargetCustomer？是不是又把商業邏輯的字眼命名到資料庫邏輯了呢？
所以最後面還是是決定直接使用User::where()->get()嗎？

等等！講這麼多我都亂掉，差點說服自己不使用Repository！來畫圖好了！

只有一個孩子(API)的時候是多麼的單純

後來多生了一個弟弟出來，但弟弟年紀還小，所以多給他一個Transformer當玩具

哥哥開始上小學了，需要買書包文具(SlashCommands)

哥哥說書包很重，我們該考慮在他的肩膀施打狂爆肌肉增長劑嗎？

畫完之後經過深思熟慮，決定還是不要用Repository好了！
以目前的專案內容來說，沒有複雜到需要將資料庫邏輯從Service獨立出來做處理，
但也發現了未來可能的問題，Service的內容變得很雜，有呼叫API、操作資料庫build陣列！
到那時候可能要再另外找解法了！

所以今天的結論是在了解Repository，並且決定不使用。