Роль модели в сценарии текстового редактора MVC

Question

Я разрабатываю текстовый редактор для редактирования сценариев фильма, чтобы развлечься и попытаться узнать кое-что о дизайне пользовательского интерфейса низкого уровня. Формат сценария довольно прост и по давним стандартам написан исключительно в 12pt курьером. Поэтому у меня сложилось впечатление, что разработка редактора была бы довольно простой, имея только один шрифт и размер шрифта без специального форматирования.

Я заинтересован в сохранении семантической информации - например, я хочу, чтобы заголовок сцены сохранялся как заголовок сцены, а не только как текст, отформатированный как заголовок сцены.

Приложение дополнительно усложняется отслеживанием изменений, требуемым в сценариях. Дополнительные страницы должны иметь информацию о редакции вверху, поэтому документ должен храниться в виде набора страниц с соответствующей информацией, идентифицирующей редакции.

Кажется, имеет смысл сохранить документ как отдельный объект от представления, а затем вызвать методы объекта документа для добавления текста и т. Д. На основе ввода в представление. Однако какой объект отвечает за нумерацию страниц? На первый взгляд, я бы сказал, что документ, но нумерация страниц выглядит как презентация. Для документа также не имеет смысла использовать API графического текста для измерения строк и определения того, сколько места они занимают. Однако, если это зависело от представления, это теоретически может вступить в конфликт с тем, как оно было сохранено в документе. Так что будет лучшим решением?

У меня большой опыт в программировании, но я не имел ничего общего с мелочами рисования собственных пользовательских элементов управления с нуля. Я также сознательно избегал привязывать это к определенному языку, но я бы, скорее всего, писал на C # или C ++.

Спасибо за ваше время.

Answer 1

Однако, если это было до вида, это теоретически может вступить в конфликт с тем, как оно было сохранено в документе

Почему?Документ представляет собой данные с некоторой семантической информацией.Какую часть этих данных вы отображаете на странице, это не то, что вы хотите сохранить в документе.

Держите свой документ в полном неведении относительно номеров страниц, размеров страниц или того, какое содержимое попадает на страницу, и выВы сможете сохранить всю логику представления в своем представлении.

Подумайте об отношениях между HTML и вашим браузером - HTML ничего не знает о страницах, о том, как они отображаются, как они печатаются и т.*

Answer 2

Если понятие «страница» на самом деле представляет собой данные, которые должны оставаться неизменными вместе с остальными данными, независимо от того, как они отображаются, то я бы проголосовал за то, что они идут в модели. Это неортодоксально, это точно. Но вы подразумеваете в своем описании, что «страницы» являются фактическими сущностями данных. Если это так, то модель страницы должна знать все, что ей нужно знать о себе, включая объем текста, который она может вместить (что не должно быть ужасно сложно, учитывая, что ваша модель данных предполагает / требует определенного шрифта для отображения ... что нужно будет как-то применять изнутри модели, и я не знаю, как).

Не похоже, что представление действительно решает, как отображать страницы, но в этом случае требования к отображению являются бизнес-логикой. Представление просто обрабатывает фактический дисплей в соответствии с этими требованиями.

Стандартная мысль по этому вопросу заключается в том, что «если речь идет об отображении, он не относится к модели». Но у каждого правила есть исключение. Если сохраняемые данные являются набираемыми данными, то у модели нет другого выбора, кроме как знать что-то, что интуитивно похоже на отображение. Вы захотите хорошо документировать это в комментариях и тому подобном, но это звучит как хороший случай исключения из интуитивного правила.

Answer 3

Ни представление, ни модель IMO не отвечают за нумерацию страниц.Это работа контроллера в парадигме MVC.Конечно, у вас есть кое-что для представления пейджера в представлении, но фактическая работа контроллера для контроля того, сколько записей отправляется в представление.

Конечно, сам класс пейджера является моделью, ноего реализация должна лежать в контроллере.