2010-10-08 23 views
5

我的問題是我們嘗試使用MVC(PHP)框架。討論了很多後,認爲MVC非常好,但我錯過了編寫可重用模型(應用程序)邏輯的可能性。所以,我不確定我們是否有正確的方法在MVC框架中實現我們的軟件。如何在MVC模型中編寫可重用的業務邏輯?

首先我要介紹一下我們目前使用的非MVC,oo方法。

例如 - 我們正在研究一些瀏覽器遊戲(是的,這是我們的專業)。想象一下我們有一個玩家對象。我們經常使用這個播放器對象。我們有一些可供您購買的不同頁面,因此您需要在玩家「銀行賬戶」上進行「金錢」交易,或者想象您可以對其他玩家進行交易。我們有幾個戰鬥腳本,這些腳本需要2個或更多的玩家對象(這取決於戰鬥類型,即戰隊戰鬥,玩家vs.玩家戰鬥......)。

所以,我們有幾個頁面(和控制器)與不同的戰鬥邏輯。但是每個控制器都使用玩家對象來計算玩家擁有的所有屬性和物品以及玩家將會執行哪些傷害和防禦。

那麼,在MVC模型的情況下,我們如何重用播放器對象中的邏輯?在不同的戰鬥控制器和模型中複製所有必要的邏輯將是不好的。

我認爲「黃金交易」 - 邏輯將是一個很好的例子,給你一些更多的細節信息。在戰鬥中需要交易功能,如果你贏了其他玩家並且掠奪了他的一些黃金,那麼在購買某些東西時你需要交易功能,並且在花費一些黃金時需要交易功能玩家公會...

所以,我會說這將是一個壞方法來定義所有這些功能在一個球員模型!我可以說你們這些玩家模型會很大(其實我們的玩家級別真的很大 - 它是一個神級)

你認爲這個問題有MVC風格的解決方案嗎?

回答

1

我會說你把代碼放在最有意義的地方,以及你不需要在其他地方複製它的地方。

如果有一些操作始終需要一個Player對象,但可能在不同的控制器中使用,則Player類將是放置該對象的合理位置。另一方面,如果一點邏輯只需要在某個Controller的上下文中完成,並且可能包含其他類,那麼它可能應該放在控制器中,或者也可能放在其他類中。

如果您在計算邏輯應該到哪裏時遇到困難,這可能是因爲您的函數沒有粒度和足夠的可重用性。毫無疑問,MVC的一些方面會迫使你更多地考慮關注點的分離和保持事情的干擾,而不是一種「普通的」面向對象的方法......所以你最終可能會分解當前編碼的操作現在可以在不同的類中使用多個函數來在正確的位置獲得正確的代碼。例如 - 這些並不是特定的建議,而只是一個隨機可能的思考過程 - 可能需要將玩家之間轉移「黃金」的過程分解爲更細化的過程。玩家階層可以完成改變餘額的基本任務,但是控制人員可以執行該過程的特定部分,例如驗證黃金被轉讓給誰以及誰轉讓以及爲什麼。