Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Протестируйте каждый компонент React

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

Соблюдайте правила линтера

Линтинг – это ценный инструмент для обеспечения качества и надежности вашего кода. Он включает в себя запуск программы, которая анализирует ваш код на предмет потенциальных ошибок и проблем. Хотя линтинг обычно используется для выявления проблем, связанных с языком, он также может автоматически устранять многие другие проблемы, включая стиль кода. Использование линтера в вашем коде React может помочь вам исправить все ошибки и недочёты, экономя ваше время и усилия в долгосрочной перспективе. В целом, линтинг – это ценная практика для любого разработчика React.

Используйте такой инструмент, как Bit

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

Используйте библиотеки фрагментов

Использование фрагментов кода – ценная практика для ReactJS, поскольку она помогает вам оставаться в курсе правильного синтаксиса и минимизировать вероятность ошибок в вашем коде. Существует множество доступных библиотек фрагментов, таких как ES7 React, Redux, JS Snippets и другие, которые вы можете использовать. Включение фрагментов кода в ваш рабочий процесс может сэкономить ваше время и гарантировать высокое качество вашего кода.

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

Некоторые основные проблемы, с которыми сталкиваются разработчики React:

— Ремонтопригодность. Когда требования к приложению растут, компоненты становятся более сложными, и их становится сложнее поддерживать.
— Плохое понимание того, как React работает под капотом. Разработчики могут слишком быстро переходить к промежуточным или продвинутым концепциям, не имея прочной основы.
— Использование версий, описанных в туториале. Если следовать примерам из устаревшего туториала, можно столкнуться с ошибками.
— Путаница между функциями и классами. Важно обращать внимание на то, как написаны различные методы.
— Ошибки в применении объекта состояния. В компонентах-классах можно объявить локальный объект state, а позже получить его значение через this.
— Неиспользование инструментов разработчика React и Redux. Отладка часто является трудоёмкой задачей, поскольку в большинстве случаев задействованы многие компоненты.
— Прямое изменение состояний. Состояния в React JS неизменяемые, и разработчики не должны пытаться обновлять их напрямую.

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

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

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

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

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

Основное отличие GraphQL от REST API заключается в их структуре и подходе к доступу и манипулированию данными.

GraphQL использует единый, гибкий endpoint и язык запросов для запроса конкретных данных. Клиент может выбрать все данные одним запросом, даже если они будут располагаться в разных источниках. Это позволяет избежать избыточной или недостаточной выборки данных, сокращая объём ненужной информации, передаваемой между клиентом и сервером.

REST API используют несколько endpoints, представляющих ресурсы, со стандартными методами HTTP для выполнения операций. Из-за жёсткой структуры REST API нужно постоянно прописывать путь к данным, которые хочет получить клиент, делая выборку.

Таким образом, GraphQL упрощает разработку на стороне сервера и позволяет легче управлять версионированием и развёртыванием, в то время как REST API более прост и подходит для небольших проектов

Ясно, спасибо. А чем GraphQL отличается от rest?

Выбор между gRPC и GraphQL зависит от конкретных требований проекта к производительности, поддержке платформ, сложности запросов и особенностей архитектуры приложения.

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

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

При необходимости эти технологии можно комбинировать в гибридных API, используя сильные стороны каждого подхода. Например, можно добавить GraphQL слой поверх существующего REST API или применять gRPC для внутреннего обмена данными, оставляя REST API для внешних клиентов

А что лучше grpc или GraphQL?

Почему хорошо использовать GraphQL

— Гибкость. GraphQL не накладывает ограничений на типы запросов, что позволяет использовать его как для традиционных CRUD-операций (create, read, update, delete), так и для запросов, которые содержат несколько типов данных.

— Определение схемы. GraphQL автоматически создаёт схему для API. А за счёт иерархической организации кода и объектных отношений снижается его сложность.

— Оптимизация запросов. GraphQL позволяет клиентам запрашивать только ту информацию, что им нужна. Это уменьшает время ответа от сервера и количество данных, которые нужно передавать по сети.

— Контекст. GraphQL учитывает все детали запросов и ответов, что позволяет разработчикам фокусироваться на бизнес-логике. А строго типизированные поля предупреждают разработчиков об ошибках перед выполнением запроса.

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

Все равно не мого понять. Почему хорошо использовать GraphQL, многие об этом говорят в том числе и наши ИТ-отдел но не понятно в чем именно суть, зачем нужно?

На самом деле объяснить GraphQL можно намного проще:

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

— schemas (схемы),
— resolvers (преобразователи),
— queries (запросы),
— mutations (мутации).

Схемы. GraphQL использует строгую систему типов, в которой все типы данных записываются на языке определения схем GraphQL (SDL). Типизированные схемы определяют формы данных, которые могут запрашиваться в API, а также взаимосвязи между типами и операциями, доступными пользователю.

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

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

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

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

Когда поступает запрос, GraphQL проверяет его на соответствие определениям схемы и, предполагая, что запрос корректен, выполняет его. Структура обычно отражает структуру данных ответа, что делает требования к виду информации более понятными.

Мутации. Это операции, которые создают, обновляют или удаляют данные на сервере. Они аналогичны операциям POST, PUT, PATCH и DELETE в RESTful API. Хотя пользователи могут получать доступ к некоторым запросам без аутентификации, мутации всегда требуют ее наличия (например, с помощью токена). Аналогично запросам, мутации в GraphQL проверяются на соответствие схеме и ее определениям. Как только мутация проверена и запущена, сервер возвращает ответ в формате JSON (текстовый формат на JavaScript).

В чем преимущества GraphQL

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

Совместимость со сложными системами и микросервисами. Сервер инструмента используется для получения данных из существующих систем и представления их в формате ответов. Это наиболее подходящий формат для устаревших инфраструктур или сторонних API, которые огромны по размеру и сложны в обслуживании и обработке. Когда нужно переходить от монолитного серверного приложения к архитектуре микросервисов, GraphQL помогает управлять взаимодействием между несколькими микросервисами. Он объединяет их в одну схему.

Отсутствие проблем с избыточной или недостаточной выборкой данных. Ответы REST иногда содержат слишком много лишней информации, а иногда ее недостаточно. Из-за этого нужного создавать повторные запросы. В GraphQL эта проблема решена. Инструмент извлекает только точные и выборочные данные в одном запросе.

Определение формы данных. При отправлении запросов сервер возвращает ответ в простой, безопасной и предсказуемой форме. Это облегчает написание конкретного запроса в соответствии с требованиями.

Строгая типизация. GraphQL — это язык со строгой типизацией, в котором каждый уровень запроса соответствует определенному типу. А каждый тип описывает набор доступных полей. Он похож на SQL и предоставляет описательные сообщения об ошибках перед выполнением запроса.

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

Преимущества и недостатки GraphQL

Сопоставление плюсов и минусов поможет решить, нужен ли GraphQL вашему проекту – или лучше обойтись REST API.

Преимущества GraphQL:
— Клиент может получать только те данные, которые ему нужны.
— Типизация и автоматическая валидация позволяет клиентам легко понять, какие данные и типы доступны в API, и точно формулировать запросы.
— Клиенты не зависят от серверных изменений в структуре данных.

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

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 параметры, были бы более наглядными), но суть я надеюсь Вы уловили.

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

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, в следующих своих проектах? Ответ: думаю да.