模型在MVC文本編輯器場景中的角色

Question

我正在設計一個電影劇本編輯文本編輯器以獲得樂趣，並嘗試瞭解一些關於低級別UI設計的內容。電影劇本的格式非常簡單，並且是由長達12個月的快遞標準編寫的長期標準。所以我覺得設計一個編輯器相當簡單，只有一種字體和字體大小，而且沒有特殊的格式。我很想保留語義信息 - 例如，我希望場景標題可以存儲爲場景標題，而不僅僅是作爲文本格式化爲場景標題。

腳本中所需的更改跟蹤使應用程序變得更加複雜。其他頁面應該在頂部有修訂信息，因此文檔需要以一組頁面的形式存儲，並具有標識修訂的適當信息。

將文檔保持爲與視圖不同的對象似乎有意義，然後根據視圖中的輸入調用文檔對象上的方法以添加文本等。但是，哪個對象負責分頁？起初猜我會說這個文件，但分頁看起來像是一個演示文稿。對於文檔來說，使用圖形文本API來測量字符串並計算出它們佔用的空間也是沒有意義的。但是，如果這是出於觀點，理論上這可能與它在文檔中的存儲方式相沖突。那麼最好的解決方案是什麼？

我在編程方面有很多經驗，但與從零開始繪製我自己的用戶控件的本質有很少關係。我也故意避免將它綁定到特定語言，但我很可能用C＃或C++編寫。

謝謝你的時間。

Answer 1

國際海事組織不負責分頁。這是MVC範例中控制器的工作。當然你會有一些東西在視圖中代表尋呼機，但是控制器的實際工作是控制有多少記錄被髮送到視圖。

當然，pager類本身是一個模型，但它的實例應該位於控制器中。

Answer 2

但是，如果達認爲， 這是在理論上容易衝突 它是如何被存儲在 文件

爲什麼？文檔是數據，帶有一些語義信息。您在頁面上顯示的數據量不是您想要存儲在文檔中的。

讓您的文檔完全不知道頁碼，頁面大小或頁面上的內容，並且您可以將所有的表示邏輯保留在您的視圖中。

想想HTML和你的瀏覽器之間的關係--HTML對頁面一無所知，它是如何瀏覽的，它是如何打印的等等。

Answer 3

如果「頁面」的概念實際上是需要保留的數據與其餘數據保持在一起，而不管它是如何被查看的，那麼我會投票選擇它在模型中。這是非正統的，很多是確定的。但是你在描述中暗示「頁面」是數據的實際實體。如果是這種情況，那麼一個Page模型應該知道它需要了解的所有信息，包括它可以容納多少文本（考慮到你的數據模型假定/需要顯示特定字體，這應該不是非常困難...這將需要從模型內部以某種方式強制執行，但我不確定如何）。

這聽起來不像是視圖真的在決定如何顯示頁面，而是在這種情況下顯示的要求是業務邏輯。該視圖僅根據這些要求處理實際顯示。

有關該主題的標準思想是「如果是關於展示，它不屬於模型。」但是每條規則都有例外。如果要存儲的數據是排版數據，那麼該模型別無選擇，只能瞭解直覺上感覺像顯示的內容。你會想要在評論和其他文檔中記錄它，但這聽起來像是一個很好的例外情況。