2015-06-20 64 views
3

我正在開發一個小型Web應用程序,它將擁有一個私人消息系統。當用戶登錄時,他的收到或寫入的消息將顯示在下拉菜單中的工具欄區域中。沒有新的:-)Laravel 5.1>在視圖中使用@inject來顯示內容

當用戶瀏覽頁面時,大部分時間都會顯示工具欄。因此,不是將收件箱實現注入每個可能通過routes.php調用的控制器中,而是考慮使用新刀片功能@inject。

這應該是這樣的(抽象)

  1. 工具欄視圖通過注射InterfaceMethod(基於構造器注入)@Inject
  2. ControllerMethod電話通話中ControllerMethod
  3. 服務容器提供實現
  4. ImplementationMethod返回收件箱

但我不確定這是否是一個很好的設計模式,因爲我通常對依賴注入比較陌生。我會欣賞一些泰坦。

回答

0

這裏有兩件事對我來說是錯誤的。

1)Laravel的@Inject視圖指令實際上並沒有做任何形式的「依賴注入」,儘管它的名字暗示了這一點。它實際上是使用服務位置,這是一種被廣泛認爲是反模式的模式。

基本上,通過@Inject,視圖可以訪問容器中的任何東西。它可以得到任何東西想要的。它沒有被告知它應該有什麼。這是依賴注入和服務位置之間的主要區別。

2)將服務直接注入到視圖中無疑意味着您將爲應用程序添加更多複雜性,因爲您添加了更多可將服務注入到模板中的位置。雖然它可能使事情變得更快更簡單,但是長期來看,它會讓事情變得更加困難。

3)如果在您的視圖中發生這種情況,您將如何測試如何獲取和控制數據?你可能不得不使用功能測試,雖然這不是一件壞事,但仍然不會像單元測試那樣有用。

我建議堅持事情通常是關於DI,而實際上使用DI。

+0

就像我所描述的DI在控制器(基於構造函數的注入)內的第二步中發生,而不是直接使用@inject。此外它通過合同鬆散耦合。所以測試應該不成問題。主要是我不知道哪種設計模式可能是實現我所描述的那種設計的好選擇:讓一個類將用戶收件箱輸出到每個請求,而無需將其注入到每個控制器中。 – Kristo