模型在MVC文本編輯器方案中的作用

Question

我正在設計一個電影腳本編輯文本編輯器來娛樂，並嘗試學習有關低級UI設計的知識。 劇本的格式非常簡單，並且采用長期標准，僅以12pt速遞編寫。 因此，我的印象是設計編輯器將非常簡單，只有一種字體和字體大小，而沒有特殊格式。

我熱衷於保留語義信息-例如，我希望將場景標頭存儲為場景標頭，而不僅僅是格式設置為場景標頭的文本。

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

將文檔保留為與視圖分離的單獨對象，然后根據視圖中的輸入，調用文檔對象上的方法以添加文本等，這似乎很有意義。 但是，哪個對象負責分頁？ 乍一看，我會說這份文件的，但分頁似乎是一種介紹。 對於文檔而言，使用圖形文本API測量字符串並計算出它們占用了多少空間也是沒有意義的。 但是，如果可以接受，那么從理論上講，這很可能與文檔中的存儲方式發生沖突。 那么什么是最好的解決方案？

我在編程方面有豐富的經驗，但是與從頭繪制自己的用戶控件的精妙之處無關。 我還特意避免將其與特定語言聯系在一起，但是我很可能是用C＃或C ++編寫的。

謝謝你的時間。

Answer 1

IMO的視圖或模型都不對分頁負責。 這就是MVC范例中控制器的工作。 當然，您將有一些東西可以代表視圖中的尋呼機，但是控制器的實際工作是控制向視圖發送多少記錄。

當然，尋呼機類本身就是一個模型，但是它的實例化應該在控制器中。

Answer 2

但是，如果可以接受，那么從理論上講，這很可能與文檔中的存儲方式產生沖突

為什么？ 該文檔是數據，帶有一些語義信息。 您在頁面上顯示的數據量中有多少不希望存儲在文檔中。

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

考慮一下HTML與瀏覽器之間的關系-HTML對頁面，如何查看，如何打印等一無所知。

Answer 3

如果“頁面”的概念實際上是無論數據如何查看都需要與其他數據保持一致的數據，那么我會投票贊成將其放入模型中。 這是非正統的，可以肯定的是。 但是您的描述中隱含了“頁面”是數據的實際實體。 如果是這樣的話，那么頁面模型應該知道它需要了解的有關自身的所有信息，包括它可以容納多少文本（考慮到您的數據模型采用/需要特定的字體來顯示，這應該不會很困難...需要從模型內部以某種方式強制執行，而我不確定如何執行）。

聽起來好像視圖並沒有真正決定如何顯示頁面，但是在這種情況下，顯示的要求是業務邏輯。 該視圖只是根據這些要求處理實際顯示。

關於該主題的標准思想是“如果是關於顯示，則它不屬於模型”。 但是每條規則都有例外。 如果要存儲的數據是排版數據，那么該模型別無選擇，只能了解一些直觀感覺像是顯示的東西。 您可能希望在注釋等中很好地記錄下來，但這聽起來像是直觀規則的一個很好的例外情況。