在MVC中，控制器屬於應用程序，還是可以進入共享庫？例如：（MVC）共享庫中的控制器？
//this is a shared library
LibShared
//these are two apps
appA ->LibShared
appB ->LibShared
不應該每個應用程序實現自己的MVC和使用任何共享庫，可能是應用程序的邏輯模型的一部分，或者只是另一個庫引用（公用事業）？
此外，有沒有一種情況下MVC控制器卡在共享庫？我認爲控制器需要位於特定應用程序中的特定視圖。意思是，控制器必須在那個應用程序？
或者控制器可以是通用的（即共享庫）嗎？這不就是說他們不再是控制者嗎？
我想任何代碼都可以去任何地方，什麼會促使我們把東西放在共享庫中或保存在應用程序中？
我會考慮兩件事：
1）。變化率是多少？當我們改變應用程序的整體時，這可能會改變。 2）。其他任何事情都需要使用它嗎？如果是這樣，當我發佈一個新版本時，其他客戶立即
通常情況下，控制器將與應用程序強烈關聯，因此對任何其他應用程序沒有太大興趣，並且它可能是應用程序更改的基礎。因此，與應用程序打包是有道理的。
現在，如果控制器在某種程度上更通用，那麼配置驅動，然後共享庫是有道理的。
控制器即使在相同的操作系統中也不一定需要。你可以在Windows中看到一個視圖，在Unix中有一個控制器，在Sparc中有你的模型。記住MVC只是一種模式，你可以做一些更強大和更容易修改的方法。
您的控制器可能是一個共享庫。你的控制者是否應該意識到你的觀點？不必要。這取決於你如何處理模塊間的通信。在一個好的MVC實現中，模塊只需交換消息或事件。所以，一個視圖發送一個事件給控制器，控制器決定該怎麼做，併發回一個消息。控制器的響應可能類似於「Show Window X」。請注意，視圖模塊可以解釋「窗口X」，如果視圖是Web模塊，那麼視圖只需放置正確的aspx頁面。如果你有另一種看法是碰巧是一個Web應用程序，那麼渲染表格X.
至少在CakePHP以及Mike McShaffry在其Game Coding Complete書中解釋的架構中，控制器確實屬於應用程序。
但是，在這兩種情況下，架構都是這樣的：應用程序從框架中繼承了模型，視圖和控制器的基本功能。
例如：
// "super" controller of all applications using this framework
class Controller
// uses basic libraries that allows the inheriting applications to work minimally
class AppController extends Controller
// mainly uses the parent class's methods but can also substitute to using
// additional libraries
通過框架在這裏我的意思是封裝類庫使用的系統。在CakePHP中，這個封裝又是通過在模型，視圖和控制器中使用庫來完成的。因此，這些組件都不會附屬於圖書館。
然而在Mike McShaffry的架構中，只有控制器和視圖使用庫。所以這些模型沒有耦合，因此非常適合不同的應用。
如果您有這樣的要求（即立即重複使用），我建議您只應將控制器分離到他們自己的模塊/包/庫（在此稱爲模塊）中。如果目前沒有這樣的要求那麼我會推遲決定什麼時候需要它，這聽起來在你的情況下，你將不必要地過度設計。從理論上講，可以稍後重構一個單獨的模塊而不會有太多障礙，但是要注意耦合，分離到不同的模塊並不會減少耦合，仔細查看控制器定向到一種樣式的依賴關係看法。
一個襯墊回答您的問題，您的應用程序是
YES，你可以移動控制器到獨立的庫沒有一個單一的線路代碼更改。