При разработке приложения на основе модели представления-контроллера (MVC), что находится в вашем арсенале инструментов?

Существует много замечательных объяснений того, что такое паттерн проектирования Model-View-Controller, но мне трудно найти хорошие ресурсы, показывающие, как использовать его на практике.

Итак, когда вы начинаете новое приложение (неважно, какое именно), что должно быть в вашем наборе инструментов?

Например, было сказано, что использование диаграмм взаимодействия UML ( http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf ) может быть полезным при разработке приложения на основе MVC, хотя я не уверен, как именно и почему это может быть так...?

Итак, что есть в вашем наборе инструментов для MVC?

Диаграммы полезны для визуализации потока данных

Данные являются основой практически каждой программы. Хорошо выполненный UML показывает, где хранятся данные (модель), что их просматривает (контроллер) и как они могут быть представлены (представление).

Конкретным примером системы MVC может быть приложение для блога. Данные, такие как записи в блоге, комментарии и т.д., могут храниться в базе данных. Это часть модели. Часть представления будет представлять собой набор процедур, которые конструируют html для страниц. Они не будут полными, они будут просто каркасом, поэтому если их запустить без ввода данных, они создадут несколько статичных визуальных элементов и несколько пустых ящиков. Они отвечают за эстетическое представление контента.

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

Важным аспектом этой парадигмы является то, что интерфейсы, представленные как каркасом представления, так и базой данных, могут быть общими. Если метод получения статьи всегда getArticle(ArticleID), то не имеет значения, как реализован бэкенд, будь то база данных SQL, хэш-база данных или набор плоских файлов. Все, что должно произойти, - это передача необработанных данных о статье.

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

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