我希望能夠將控制器、模型等從其默認的Mojolicious路徑中移出：
我希望能夠將控制器、模型等移出。
- App
- 控制器
- 命名空間1
- ...
- 命名空間2
- ...
- 模型
- 命名空間1
- ...
- 命名空間2
- ...
變成更容易管理的東西，例如：
。 - App
- 命名空間1
- 控制器
- ...
- 模型
- ...
- 命名空間2
- 控制器
- ...
- 模型
- ...
因此，而不是
$r->any('/api/test')->to('Namespace1::Controller1#test') 。
我可以呼叫類似于
的東西$r->any('/api/test')->to('App::Namespace1::Controller1#test') 。
如何在Mojolicious中完成這個任務？
uj5u.com熱心網友回復：事實證明，你可以這樣指定命名空間：
$r->any('/api/test')->to(
namespace => 'App::namespace1'。
controller => 'Controller::Controller1',
action => 'test', action =>
);
這將從控制器test方法呼叫App::Namespace1::Controller::Controller1
請參閱Mojolicious Routing了解詳情
。uj5u.com熱心網友回復：
我不知道你在做什么，但看起來你的Mojo應用程式中可能有太多的模式代碼。也許不是，但我已經見過幾次這種模式了。如果這對你不適用，就忽略它吧。它肯定適用于其他可能讀到你問題答案的人。
首先，我像你那樣做了：在to()中指定前綴命名空間。我更喜歡這樣做，因為它可以幫助我（和其他人）在有很多控制器命名空間的專案中找到該類（以及消除命名空間的沖突）。
你也可以推送命名空間的前綴：
push @{$app->route->namespaces}, 'MyApp::MyController';
人們傾向于把可能是幾個不同的服務塞進一個單一的Mojo應用程式，最終導致某種沖突。例如，考慮到兩套完全不同的路由，它們都想以/api開始，但彼此之間沒有任何關系。
控制器的作用是接收和控制事務，如果它們只關注這一點，就會好得多。更好的意思是 "我必須少打幾個字才能找到我想要的檔案"。但是，這也意味著模型不應該被綁在任何特定的控制器上。一個好的模型應該是獨立的和可重用的。這就是他們關注點分離的意義所在。
- App
- 控制器
- 應用程式的主要部分
- ...
- 不相關的App部分
- ...
- 模型
- 不與任何控制器系結
- 仍然不與任何控制器相連
當模型不是獨立的，它是專門為某個特定的控制器（或一組控制器）服務的時候，重用就會變得很混亂。我更希望有通用的模型。假設你為應用程式添加了另一個主要部分，但現有控制器的模型可以處理它。現在命名規則被打破了，因為你正在跨越與你的任務無關的命名空間。另外，我還看到人們創建了額外的模型，這些模型使用相同的源，但具有不同的介面。這就重復了代碼。
作為一個旁觀者：當你談論代碼的可讀性時，忘記了語法和陳述句。我愿意用一些難啃的代碼來換取更好的專案結構，這樣我就不必在一些奇怪的地方尋找我應該使用的代碼。例如，當我需要對狗做一些事情時，我為什么要看CatStuff.pm？糟糕的架構和組織對我來說更令人痛苦。
我傾向于喜歡命令列程式，所以我喜歡做網路應用所能實作的相同任務，但要從終端開始。而且，這里是對代碼分離的真正考驗。我可以使用相同的組件來制作終端工具嗎？如果控制器和模型是輕量級的包裝，這意味著我可以很容易地將它們包裝的東西用于一個完全不同的非Mojo專案。如果我不能輕松地做到這一點，我可能已經把控制器或模型做得太復雜了。
制作新工具應該更容易，而不是更難。這就是 "選項三角"。如果我在專案中的選擇范圍越窄（因此，接近三角形的尖角部分），我可能做錯了事情。如果我的選擇范圍擴大了，我可能做得更好。
通常的反對意見是，這些東西永遠不會相互影響。那么，這就是一個代碼管理和部署的問題。如果它們真的是兩件獨立的事情，我更希望它們能真正分開。雖然我并不總是能得到我的方式（也許甚至不是通常；），也許你也不能得到你的方式。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/311360.html
標籤：