Последние сообщения

Лицензия Enterpaise это ведь не единственный критерий, по которым вы выбрали создать портал на системе DST Portal, на чем основывались выбрав именно эту систему? 

Иван Тышковец

Конечно нет, посмотрели базовые функции — практически у всех порталов на рынке они очень похожи. Посмотрели GUI различных систем. Оценили стоимость владения (лицензии, в том числе системный софт+проект внедрения, под наши потребности+тех.поддержка). Проранжировали потребности. Для меня важна была возможность дорабатывать портал своими силами (ФОТ php-программиста пока еще ниже, чем java и .net и их проще найти). Оценили срок запуска.

Свели данные в таблицу, в столбцах рассматриваемые системы, в строках критерии по которым выбирали. В ячейках таблицы проставили то насколько система удовлетворяет заявленному критерию. В общем очень субъективно. Оказалось, что нам достаточно решения на базе DST Portal с максимальной лицензией.

Один момент в теме не указал — при выборе системы мы присвоили каждой из потребностей весовой коэффициент от 0 до 1, например быстрый поиск информации — 1, а у проведения внутренних маркетинговых компаний — 0,6. Также присвоили коэффициент таким параметрам как стоимость, срок и GUI = 1

Лицензия Enterpaise это ведь не единственный критерий, по которым вы выбрали создать портал на системе DST Portal, на чем основывались выбрав именно эту систему? 

Спасибо, как раз думаю о портале компании. Даже половины того что вы тут написали, не приходило ко мне в голову. Я вам очень благодарна. Читая ваши перечни, мне всё время приходила фраза: «А чё так можно?» удивлена что DST Portal такой функциональный 

Для ITшников, особенно программистов я бы добавил возможность корпоративного репозитория, на самом деле мегаактуально и доки к информационным продуктам (ну это и для службы поддержки тоже), конечно доки уже встроены в DST portal но я бы расширил функции 

Исходя из опыта, когда компания решает самостоятельно внедрить корпоративный портал, она часто сталкивается со множеством внутренних проблем: сотрудники могут быть недостаточно мотивированы и не желают выполнять задачи, выходящие за рамки их обычных обязанностей. Без четкой поддержки руководства и вовлеченности команды процесс может затянуться и выйти за рамки бюджета. Важно понимать, что автоматизация бизнес-процессов требует тщательной их проработки с самого начала и до конца. Если процессы не завершены и отложены на потом, они превращаются в хаос. Поэтому лучше доверить внедрение опытным специалистам, которые смогут провести анализ существующих процессов, грамотно управлять проектом и качественно его завершить. Успех внедрения зависит от правильных выводов, готовности к изменениям и тщательной аналитики перед запуском.

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

Как корпоративный портал способствует повышению продуктивности бизнеса. Вопрос нужен ли нашему бизнесу корпоративный портал и как его внедрить?

АйТи

Эффективность автоматизации и интеграции корпоративных порталов во многом зависит от бюджета компании. Если средства позволяют и бизнес-процессы уникальны, стоит рассмотреть более комплексные настройки. Однако для стандартных процессов оптимальны готовые решения, такие как DST portal о котором тут написано, хотя они имеют ограничения в лицензии «Бизнес», лучше сразу брать лицензию «Премиум». SharePoint — тоже хороший вариант, но его использование в России сейчас сокращается. Кстати, текущая тенденция — переход на отечественные или самописные решения, поскольку зарубежное ПО, вроде продуктов Microsoft, становится менее доступным.

Реализация корпоративного портала — важный шаг, требующий строгого следования плану и активного участия всех сторон. Особое внимание уделяется на каждом из этих этапов:

— Техническая разработка: следите за соответствием спецификациям, чтобы избежать проблем с совместимостью. Регулярно общайтесь с разработчиками и пользователями для своевременного решения возникающих вопросов;

— Тестирование: проведите комплексное тестирование до запуска, чтобы обеспечить стабильную работу портала;

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

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

Возможные проблемы и пути их решения

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

Недооценка времени и ресурсов, необходимых для внедрения портала — частая ошибка.

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

Интеграция нового портала с существующими базами данных и системами может также оказаться сложной задачей.

— Решение: изначально проанализировать совместимость и требования. Привлечь экспертов и учесть всю информацию о текущих системах в проекте.

Игнорирование вопросов безопасности может привести к серьезным рискам утечки данных или несанкционированного доступа.

— Решение: обеспечить соответствие системы актуальным стандартам безопасности и использовать современные методы шифрования и аутентификации.

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

— Решение: минимизировать риски с помощью регулярного тестирования и привлечения опытных IT-специалистов для оценки инфраструктуры перед началом проекта.

Могу точно сказать, перед выбором и внедрением корпоративного портала необходимо провести анализ текущих бизнес-процессов компании. Важно оценить, как работают и взаимодействуют уже существующие системы.

Внедрение корпоративного портала индивидуально для каждой компании. Оно зависит от многих факторов: наличия существующих систем, корпоративной культуры и специфики бизнеса. Универсальных решений не существует; каждый проект требует учета уникальных особенностей компании.

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

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

— Сбор требований: необходимо получить информацию от стейкхолдеров — руководства, рядовых сотрудников и IT-специалистов. Это поможет учесть все аспекты бизнес-процессов и избежать внедрения ненужных функций;

— Выбор платформы: в зависимости от требований, можно выбрать готовое решение (например, ДСТ Портал, Microsoft SharePoint) или разработать собственный портал. Все зависит от бюджета, технических возможностей, интеграции с другими системами и требований к безопасности;

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

— Планирование внедрения: после утверждения проекта создается детальный план по разработке, тестированию, внедрению и обучению пользователей работе с порталом. Здесь важны управление изменениями и сбор обратной связи — это помогает адаптировать портал к реальным условиям работы и вовремя реагировать на возникающие проблемы.

1. Не правильно предполагаете — просто некй экшен может просто отдавать статику, а значит ему не надо дергать модель. Или же наоборот — он отвечает на некий ajax запрос, или режим работы апи — тогда он не рендериит ничего, а отдает данные например в виде json. так же в контроллере вполне может происходить некая предвариительная проверка / валидация форм…

2. Это было относительно недостатков раздела 1, где описано кто что делает и как все плохо из-за этого. Просто тут имхо на не совсем мелком проекте хотябы без хелперов никуда, иначе появится дублирование кода или базовые классы будут сильно обрастать функционалом — имеются ввиду базовый контроллер / модель / въюха

3. Никакой ошибки там нет. Без модели конечно сложно пример придумать в чистом MVC, но думаю тоже найдется если подумать.

3.1. Пример без вьюшек уже приводил — когда аджакс запрос, ожидающий данные в json или в вииде строки, любой api почти всегда тоже будет без вьюшек.

3.2. Без контроллера — тоже без проблем, есть модель которая тянет данные со стороннего сервиса через апи, эти данные нужны лишь в отдельном блоке сбоку, но никогда не открываются как отдельная страница.

3.3. Касательно функциональных модулей — я пишу о том же, абсолютно о том же.

4. Вы пишите что больше и этого уже достаточно. Если говорить об урл, то при текущих серверах это пренебрежимо мало и не стоит это относить к недостаткам. Я же писал о том как было ранее — получили данные из БД, они как правило в виде обычного массива, далее оперируют этим массивом. Если передавать массив и он большой, то по умолчанию он будет копироваться и да, будет кушать память. Сейчас же это скорее будет некая коллекция и передаваться будет в виде объекта, а он по умолчанию не будет копироваться и кушать память

4.1. В MVC контроллер не должен разбирать урл. Урл должен разбираться до контроллера, либо как-то напрямую, но лучше в неком классе Request и уже на основе этого урла разобранного как-раз и будет подключаться и вызываться некий метод некого контроллера

1. Controller -> Model -> View — это я написал упрощенный вариант последовательности, конечно, если вдаваться в подробности, то цепочка будет иметь вид CMCVC.

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

2. Я написал исключительно свое мнение о применении MVC в своем проекте, где использовал MVC в чистом виде. Я ни слова не сказал как его обычно применяют при реализации «среднестатистических проектов». К чему это утверждение я не понимаю.

3. Я пишу о функциональных модулях программы. Функциональный модуль — это некий логически завешенная часть программы, реализующая какую нибудь самостоятельную функцию. Например, функциональный модуль отвечающий за комментарии пользователей. Такой модуль включает в себя элементы контроллера (загрузка параметров для комментариев), элементы модели (загрузка данных из СУБД и применение параметров определенных контролером) и элементы отображения (механизм визуализации комментариев).

Учитывая Вашу ошибку из 1-го пункта (где часть логики работы программы находится в контроллере), я согласен, что не во всех случаях необходимо подключать модель или отображение (не всегда есть необходимость обращение к данным или визуализации результатов). Но при правильно организации, программа без модели будет бессмысленна.

4. «но не на так много как вы описываете» я и не пишу, что на много больше, я пишу что больше.

Мне не понятно как выбор подхода (функциональный или объектно ориентированный) влияет на объем памяти, необходимый для хранения данных? Например, одним из параметров программы (в моем проекте) является URL, как известно это обычная строка. В MVC контроллер разбирает URL и распределяет его части в переменные (URL «server/ru/blog/» загружается в 3 переменные/свойства $server, $language и $category). Далее модель будет оперировать исключительно этими переменными.

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

Может пример с URL я подобрал не очень хороший (POST параметры, были бы более наглядными), но суть я надеюсь Вы уловили.

Мой путь к MVC

Некоторое время назад, мной было принято решение сделать свой блог. Повозившись какое-то время с WordPress пришел к выводу, что «там рыбы нет» (и сегодня, глядя на статистику запросов к сайту считаю, что отказ от WordPress было правильным решением). В общем, проанализировав совокупность внешних факторов (мои знания, необходимое время на разработку, доп. затраты на обслуживание и т. д.) решил все разработать самостоятельно, с нуля. И т. к. теперь у меня руки были развязаны (в выборе механизмов программной организации), решил опробовать «на себе» широко разрекламированную концепцию MVC (в предыдущих проектах я использовал модульный подход).

Мое понимание MVC

Т. к. в найденной мной технической документации используются весьма заумные формулировки (типа «использует модель и представление для реализации необходимой реакции»), считаю необходимым написать свое понимание концепции MVC (чтобы не возникало недоразумений).

Итак, согласно концепции MVC, приложение должно состоять из 3-х фундаментальных логических частей: controller (контроллер), model (модель), view (представление/отображение). Блок controller – преобразует действия пользователя (в данном контексте, пользователь – не обязательно человек) во входящие параметры для Model и передает управление в Model. Блок model – реализует всю логику работы программы и подготавливает данные для отображения. Блок view – визуализирует результаты работы программы. Каждое действие пользователя всегда запускает цепочку controller->model->view.

Распишем функции каждого блока более подробно, controller:

— загружает переменные окружения (POST/GET переменные, параметры командной строки, URL параметры и т. д.);

— выполняет первичную обработку переменных окружения (проверка типов переменных, их наличие, установка значений по умолчанию и т. д.);

— реализует механизмы контроля за внештатными ситуациями;

— реализует механизмы логгирования (не аутентификации, а ведение журналов).

Model:

— выполняет конечную проверку входящих параметров (допустимость значений, диапазонов и т. д.);

— реализует взаимодействие с системами хранения данных (базы данных, файлы, SOAP и т. д.);

— реализует логику работы программы;

— подготавливает данные для визуализации.

View:

— организует механизмы визуализации результатов работы программы.

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

Недостатки концепции MVC

1. Необходимость использования большего количества ресурсов. Сложность обусловлена тем, что все три фундаментальных блока являются абсолютно независимыми и взаимодействуют между собой исключительно путем передачи данных. Controller должен всегда загрузить (и при необходимости создать) все возможные комбинации переменных и передать их в Model. Model, в свою очередь, должен загрузить все данные для визуализации и передать их во View. Например, в модульном подходе, модуль может напрямую обрабатывать переменные окружения и визуализировать данные без загрузки их в отдельные секции памяти.

2. Усложнен механизм разделения программы на модули. В концепции MVC наличие трех блоков (Model, View, Controller) прописано жестко. Соответственно каждый функциональный модуль должен состоять из трех блоков, что в свою очередь, несколько усложняет архитектуру функциональных модулей программы.

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

Преимущества концепции MVC

1. Единая концепция системы. Несомненным плюсом MVC является единая глобальная архитектура приложения. Даже в сложных системах, разработчики (как те, которые разрабатывали систему, так и вновь присоединившиеся) могут легко ориентироваться в программных блоках. Например, если возникла ошибка в логике обработки данных, разработчик сразу отбрасывает 2-блока программы (controller и view) и занимается исследованием 3-го (model). Я не раз удивлялся, насколько сильно упростилась локализация проблем.

2. Упрощен механизм отладки приложения. Т. к. весь механизм визуализации теперь сконцентрирован в одном программном блоке, упростились механизмы опционального вывода графических элементов. Я не могу оценить насколько это утверждение применимо в программировании классических приложений, но в Web программировании эта архитектурная особенность стала несомненным плюсом.

Выводы

Общее впечатление, от использования концепции MVC получилось положительным. Те сложности, которые обратили на себя мое внимание — они больше психологические (вот всегда было так, а теперь по другому). В тоже время, для меня остался открытым вопрос, насколько можно применить концепцию MVC при разработке обычных приложений (например, для Windows). На вскидку вроде можно, но не факт, что это будет оптимально.

Ну и самый главный вопрос: стану ли я использовать концепцию MVC, в следующих своих проектах? Ответ: думаю да.

Дмитрий Гольцов

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

1. Вы пишите Controller -> Model -> View — это в корни не верно, модель никакого отношения к представлениям вообще не имеет — там только логика и данные. Контроллер получает запрос, что-то с ним делает, на основании его подключает или не подключает модели, получает или не получает данные и далее может отдать их сразу или вызвать рендер представления — это в упрощенном виде, т.к. здесь еще могут быть ACL или еще неке действия связанные с другими частями приложения

2. Вы упускаете тот факт, что MVC в чистом виде сейчас редко где встретишь. Почти везде есть помощники / поведения / блоки и т.д., а так же все это подкреплено всякими реестрами / репозитариями / событиями и т.д…

3. На модули делить очень даже просто — MVC будет внутри модуля и к слову сказать — совершенно не обязательно, чтобы у модуля к примеру был свой контроллер, он вполне себе может существовать и без него, или без модели

4. На счет расходов ресурсов — подозреваю что если использовать mvc это будет кушать больше ресурсов чем тот подход, который вы описывали, но не на так много как вы описываете. MVC это ООП — а в ООП в основном оперируют объектами, а они в свою очередь передаются по ссылке — поэтому никаких дополнительных расходов ресурсов особо не происходит. Но при грамотном построении архитектуры, когда проект разрастается, его намного проще поддерживать и развивать

Мой путь к MVC

Некоторое время назад, мной было принято решение сделать свой блог. Повозившись какое-то время с WordPress пришел к выводу, что «там рыбы нет» (и сегодня, глядя на статистику запросов к сайту считаю, что отказ от WordPress было правильным решением). В общем, проанализировав совокупность внешних факторов (мои знания, необходимое время на разработку, доп. затраты на обслуживание и т. д.) решил все разработать самостоятельно, с нуля. И т. к. теперь у меня руки были развязаны (в выборе механизмов программной организации), решил опробовать «на себе» широко разрекламированную концепцию MVC (в предыдущих проектах я использовал модульный подход).

Мое понимание MVC

Т. к. в найденной мной технической документации используются весьма заумные формулировки (типа «использует модель и представление для реализации необходимой реакции»), считаю необходимым написать свое понимание концепции MVC (чтобы не возникало недоразумений).

Итак, согласно концепции MVC, приложение должно состоять из 3-х фундаментальных логических частей: controller (контроллер), model (модель), view (представление/отображение). Блок controller – преобразует действия пользователя (в данном контексте, пользователь – не обязательно человек) во входящие параметры для Model и передает управление в Model. Блок model – реализует всю логику работы программы и подготавливает данные для отображения. Блок view – визуализирует результаты работы программы. Каждое действие пользователя всегда запускает цепочку controller->model->view.

Распишем функции каждого блока более подробно, controller:

— загружает переменные окружения (POST/GET переменные, параметры командной строки, URL параметры и т. д.);

— выполняет первичную обработку переменных окружения (проверка типов переменных, их наличие, установка значений по умолчанию и т. д.);

— реализует механизмы контроля за внештатными ситуациями;

— реализует механизмы логгирования (не аутентификации, а ведение журналов).

Model:

— выполняет конечную проверку входящих параметров (допустимость значений, диапазонов и т. д.);

— реализует взаимодействие с системами хранения данных (базы данных, файлы, SOAP и т. д.);

— реализует логику работы программы;

— подготавливает данные для визуализации.

View:

— организует механизмы визуализации результатов работы программы.

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

Недостатки концепции MVC

1. Необходимость использования большего количества ресурсов. Сложность обусловлена тем, что все три фундаментальных блока являются абсолютно независимыми и взаимодействуют между собой исключительно путем передачи данных. Controller должен всегда загрузить (и при необходимости создать) все возможные комбинации переменных и передать их в Model. Model, в свою очередь, должен загрузить все данные для визуализации и передать их во View. Например, в модульном подходе, модуль может напрямую обрабатывать переменные окружения и визуализировать данные без загрузки их в отдельные секции памяти.

2. Усложнен механизм разделения программы на модули. В концепции MVC наличие трех блоков (Model, View, Controller) прописано жестко. Соответственно каждый функциональный модуль должен состоять из трех блоков, что в свою очередь, несколько усложняет архитектуру функциональных модулей программы.

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

Преимущества концепции MVC

1. Единая концепция системы. Несомненным плюсом MVC является единая глобальная архитектура приложения. Даже в сложных системах, разработчики (как те, которые разрабатывали систему, так и вновь присоединившиеся) могут легко ориентироваться в программных блоках. Например, если возникла ошибка в логике обработки данных, разработчик сразу отбрасывает 2-блока программы (controller и view) и занимается исследованием 3-го (model). Я не раз удивлялся, насколько сильно упростилась локализация проблем.

2. Упрощен механизм отладки приложения. Т. к. весь механизм визуализации теперь сконцентрирован в одном программном блоке, упростились механизмы опционального вывода графических элементов. Я не могу оценить насколько это утверждение применимо в программировании классических приложений, но в Web программировании эта архитектурная особенность стала несомненным плюсом.

Выводы

Общее впечатление, от использования концепции MVC получилось положительным. Те сложности, которые обратили на себя мое внимание — они больше психологические (вот всегда было так, а теперь по другому). В тоже время, для меня остался открытым вопрос, насколько можно применить концепцию MVC при разработке обычных приложений (например, для Windows). На вскидку вроде можно, но не факт, что это будет оптимально.

Ну и самый главный вопрос: стану ли я использовать концепцию MVC, в следующих своих проектах? Ответ: думаю да.

Удобно и красиво, как и со всеми паттернами к стати. Деление ролей по MVC красиво и удобно потому, что стратегически выгодно в больших проектах с насыщенным графическим интерфейсом. Оно, скажем так, отвечает тому как видит систему разработчик. Позволяет хорошо локализовать изменения в этих отдельных сущностях так, что вероятность их одновременного изменения ниже. Давайте на вскидку рассмотрим основные причины изменений которые видны в ДСТ Платформ:

— Изменение структуры данных — больше всех поменяется модель, котроллер меньше, а представление возможно совсем не придется менять.

— Изменение логики интерфейса — больше меняется представление, потом контроллер, модель еще меньше.

— Исправление ошибок — прежде всего их проще найти, во-вторых упрощается тестирование.

— Большие структурные изменения — их становится проще спланировать, разбить на этапы.

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

MVC — это архитектурный паттерн, который разделяет приложение на три логических компонента: модель, представление и контроллер. 

Основная идея паттерна MVC в том, что у каждого раздела кода есть своя цель. Часть кода содержит данные приложения, другая отвечает за то, каким его видит пользователь, последняя управляет его работой.

— Код модели Model хранит данные и связанную с ними логику, а также закрепляет структуру приложения. Например, если программист создаёт приложение для списка дел, код модели будет по шаблону определять основные компоненты приложения: что такое «задача» и что такое «список».

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

— Код контроллера, Controller, связывает модель и представление. Он получает на вход пользовательский ввод, интерпретирует его и информирует о необходимых изменениях. Например, отправляет команды для обновления состояния, такие как сохранение документа. В приложении со списком дел контроллер определяет, как пользователь добавляет задачу или помечает ее как выполненную.

Проще говоря — MVC — подход к проектированию приложения, который предполагает выделение кода в блоки типов модель, представление и контроллер. Контроллер обрабатывает входящие запросы. Модель достаёт из базы данных информацию, нужную для выполнения конкретных запросов. Представление определяет результат запроса, который получает пользователь. 

Таким образом DST Platform становиться логичным и понятным для почти любого разработчика, что достаточно важно т.к. нет привязки к чему то одному. 

Паттерн MVC позволяет писать независимые друг от друга блоки кода. Их можно менять отдельно, не затрагивая остальные. Так можно облегчить себе работу, разрабатывая только один программный компонент — независимо от остальных. Например, переписывать способ отображения данных, не трогая способ их обработки.

Это особенно актуально для больших команд. MVC структурирует код и упрощает тестирование, поддержку: с этим паттерном модернизировать можно отдельные блоки, а не всё приложение целиком. Модель позволяет разделить обязанности: пока один программист пишет обработчик данных, другой занят их отображением. В DST Platform это здорово экономит время: каждый работает над своей задачей, не нужно вникать в чужой код, а изменения в одном блоке не влияют на другой.