А MVC ли это?

    Добрый день!

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

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

    В чем же разница? Чтобы это понять, давайте сформулируем задачи MVC:

    1. Экранировать модель – то есть, сделать так, чтобы модель не “знала” ничего, о технической реализации приложения, о пользовательском интерфейсе, сетевых протоколах, работе с базой и даже архитектуре системы. Модель должна отображать предметную область и быть вне технологий.

    2. Отделить слой представления – значит, иметь возможность создать несколько представлений для одной и той же модели, которые могут существовать параллельно, например, для разных пользовательских устройств, браузеров, мобильных платформ и оконных приложений. Еще это дает возможность распараллелить работу, вводя разделение труда с GUI программистами и даже дизайнерами, которые могут делать шаблоны отображения, но в код лезть не должны.

    Вот собственно и все – есть две части системы, и нам нужно сделать так, чтобы они меньше зависели друг от друга. И так как модель не должна “знать” о представлении, то вводится третья сущность – контроллер, который “знает” обе части системы и, грубо говоря, может делать к ним вызовы. Вот тут и начинается путаница.

    Первое, в чем мнения расходятся, это где должна располагаться логика приложения. Одни помещают всю логику в модель и делают из контроллера тонкую прослойку, другие же, наоборот – наращивают функциональность контроллера, оставляя в модели только данные. В этом случае контроллер наполняется классами, имена которых говорят о их принадлежности к предметной области с приставками “Manager”, “Dispatcher”, “Logic”, “Controller” и т.д. По сути, есть два варианта: сделать контроллер ядром системы или сделать его прокси-прослойкой. Но есть и класс задач (графические приложения с развитой визуализацией и игры), когда представление настолько тесно связано с моделью, что модель содержит непосредственно координаты, поведение и особенности рендеринга, а контроллер испаряется. Это называется MVVM (Model-View-ViewModel), а как оказалось в последствии, это удобно и для широкого круга прикладных задач, связанных с вводом данных, управлением оборудованием, и т.д.

    Второе разногласие в том, кто должен работать с базой данных. Кто-то помещает запросы к данным в модель и говорит, что модель должна сама знать как ей “подыматься” и сохраняться, другие – помещают обращения к СУБД в контроллер, третьи – выделяют еще одну составляющую системы специально для работы с базой, называя ее “Хранилище”, “Репозиторий” или даже “ORM” (то есть объектно-реляционное отображение). По запросу контроллера, ORM порождает объект модели и, по его же запросу, ORM может сохранить, модифицировать или синхронизировать объект с базой данных.

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

    Наконец, последний пункт разночтений проявляется в смешении архитектурного подхода MVC с трехзвенной архитектурой: СУБД-СерверПриложений-Клиент, которая надолго закрепилась в умах, особенно у старшего поколения разработчиков. На самом деле MVC и трехзвенка, это не одно и то же, но они могут существовать параллельно. Например, в веб-приложениях, все три звена могут располагаться на сервере и только лишь рендеринг готовой страницы будет происходить в веб-браузере. Другой вариант, и он более современный, когда в браузере запускается клиентское JavaScript приложение, полностью или частично реализующие слой представления. Для этих целей появились даже JavaScript-шаблонизаторы. Но полностью перенести представление в браузер на сторону клиента нам не удастся, разве что, при полном отказе от HTML и сведении страницы к одному тегу подключения JavaScript. Это уже экстремизм, я даже не говорю про SEO, мобильные браузеры и отключенный JavaScript.

    Таким образом, все представляют себе MVC по-разному, и реализуют под этой вывеской совершенно разные архитектуры, условно обозначим их: Mvc, MVc, mvC, mVC и т.д. Все это происходит потому, что сама задача таит в себе противоречие. Чтобы сделать модель и представление независимыми, совсем не нужно разделять данные, логику и отображение. Это совсем разные вещи. В каждом отделенном звене все равно будут находиться данные, логика и отображение, например: логика данных в базе и хранимые процедуры; логика отображения в пользовательском интерфейсе; бизнес-логика или логика модели; данные содержатся и в пользовательском интерфейсе и в контроллере; интерфейс – это не только интерфейс, но и интерфейс пользователя между моделью и контроллером.

    Получается, отделить модель от контроллера и вью невозможно? Возможно, но для этого нужно отказаться от разделения данных, логики и представления. Как это ни парадоксально, но MVC работает только в случае, если Model, View и Controller реализованы на разных уровнях абстракции. Model – должен содержать как данные, так и логику предметной области и в грамотном объектно-ориентированном программировании должен совпадать с понятием “объект предметной области” или “отображение объекта реального мира”. Model – это, прежде всего, моделирование, а это включает в себя информационную модель, логическую модель и даже модель визуализации, для некоторых задач. Объект предметной области не должен знать, как он хранится в базе данных, передается между программными модулями и по сети. Он запускается в приложении, как в виртуальной машине и, в идеальном случае, должен быть переносим даже между системами. Как раз по этому, я настаиваю на написании логики модели на скриптовых, интерпретируемых языках (личное предпочтение – JavaScript). Это не исключает скорости работы модели, потому, что скрипт может компилироваться в код нативного языка или сразу в байт-код и кэшироваться на продолжительные отрезки времени. Что же касается пользовательского интерфейса, то часть модели всегда будет содержаться и в нем, а если она будет на JavaScript, то мы сможем запускать такие вещи, как бизнес-логику, валидацию и матмодель, частично на сервера, а частично на клиенте. Некоторые части только на клиенте или только на сервере, а некоторые – и там и там, не переписывая их по много раз. Что же тогда View? А View – это рендерер (для веб-приложений – браузер), плюс библиотека визуальных компонентов (уж простите старого дэлфиста), плюс шаблоны и стили.

    Что же остаетсается контроллеру? Controller – это та виртуальная машина, в которой запускается объект предметной области. Контроллер не должен переписываться для каждого приложения, это Application Framework (прикладная платформа). Причем, часть контроллера работает на стороне сервера, а часть в браузере. Контроллер забирает данные у модели на стороне сервера и передает по сети. С другой стороны, в браузере, контроллер же ловит данные и передает их для визуализации, а так же, разворачивает часть модели, которая нужна на клиенте, чтобы не гонять данные по сети при каждом действии пользователя. Откуда я это взял? А вспомните семь уровней модели ISO/OSI, кроме вертикального взаимодействия между слоями, в ней есть еще и горизонтальное (логическое) взаимодействия – протоколы. На разных сторонах соединения транспорт логически взаимодействует с транспортом, а модель должна взаимодействовать с моделью, а фреймворк – с фреймворком (см. рис.). При этом, они имеют разные уровни абстракции в вертикальном взаимодействии, а в горизонтальном, находятся на одном уровне.



    Таким образом, у нас появилась модель Storage-Model-Application-Renderer-Template-Model, сама собой, хорошо сокращаемая в SmartModel, что отражает смысл подхода. Но это уже из области метапрограммирования, и подробнее об этом я расскажу в отдельной статье.

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

    Спасибо за внимание.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 47

      +7
      Есть еще одно популярное разночтение. Очень многие под View подразумевают лишь шаблонизатор и вызывают его прямо из контроллера, в то время как есть и иной взгляд — что View лишь представляет полученные от контроллера данные в понятный для шаблонизатора вид, попутно дополняя их данными, не зависящими от текщего пользовательского ввода (например строчку с информацией об авторизованном пользователе).

      Поэтому при каждом шевелении в пользовательском интерфейсе, управление попадает в контроллер.

      По-моему только так и должно быть. Каждому делу — своя группа классов. Лишь один компонент отвечает за обработку пользователького ввода — контроллер. Как исключения — случаи общей пре-обработки, вроде авторизации или выбора локали.
        +8
        Ох, сударь, отсыпьте!
          +9
          По мне так придумывание лишних-новых сущностей и уровней есть зло. В общем случае стоит свести все к взаимодействию субъекта над объектом, и тут можно выделить три базовых уровня: над чем оперируем (модель), как оперируем (вид), правила взаимодействия (контроллер). В таком случае клиент-сервер стоит рассматривать не как множество разных слоев, а как иерархическую модель mvc.

          Например, классы данных (entity) на сервере будут моделью, классы для получения данных (dao, service) будут видом, а связующая логика (interceptors, security, ioc) будет являться контроллером. Причем в данном случае вид (можно взять другой термин) не будет иметь визуального представления, он будет только предоставлять интерфейс для работы с данными. Тоже самое можно сказать и об интерфейсе пользователя (модель — данные с сервера, вид — интерфейс пользователя, контролер — связующий фреймворк).

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

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

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

          p/s
          Кстати, большое количество кода бизнес логики на клиенте (клиентский javascript толкает к этому) ведет к еще одной проблеме: надо валидировать не только данные на клиенте и сервере, но и правила вызова методов (функций) на клиенте и сервере. Но такова судьба…
            +12
            Я думаю, что большинство программистов, независимо от их собственного мнения, ориентируются на систему MVC, предложенную тем фреймворком, на котором они пишут.

            И лишь те сотни (тысячи?) программистов, формирующих архитектурную политику фреймворков / крупных проектов — вкладывают в это собственное мнение.

            Это если не учитывать программирование for fun с нуля.
              +12
              Чем ваша точка зрения отличается от ещё одной из тех, что вы перечислили в начале? MVC — это идея, а как её реализовать, решает каждый сам, исходя из поставленной задачи и условий, в которых находится. И это не серебряная пуля, городить везде MVC — не самый удачный вариант. Как и городить везде JavaScript.

              Лично я всегда придерживаюсь двух правил: частное лучше общего и меньше — больше. Очень, знаете ли, помогает.

              P.S. Sencha (бывший ExtJS) вполне нормально используется в админках, и выглядит чаще всего именно как один скрипт, подключенный к пустой HTML страничке. Ничего радикального, очень удобный фреймворк.
                0
                Отличается: я подчеркиваю, что разделение модели, контроллера и представления не идентично разделению данных, логики и интерфейса. В результате предлагаю MVC разделять, а все, что касается предметной области (данные, логику и интерфейс) наоборот объединять. Еще — стараюсь показать, что есть много взглядов на одну задачу и не нужно думать, что произнося MVC Вас сразу все поймут однозначно, как, наприер, если Вы произносите «наследование» или «фабрика». Ну и последнее — провожу парралели с ISO/OSI, показывая, что в трехзвенке (если речь идет о веб-приложении, а не просто сайте) модель должна быть развернута частично во всех трех слоях, чтобы были адекватные горизонтальные связи.
                  0
                  Вы не поняли меня :) Я имел ввиду, что ваша точка зрения — одна из многих, вот и всё.
                    0
                    Тогда согласен, я об этом же, в последнем абзаце: «Я не претендую ни на авторство… ни на то, что это единственный и самый правильный подход».
                +1
                http://martinfowler.com/eaaDev/uiArchs.html

                Рекомендую к прочтению
                  +1
                  http://www.ozon.ru/context/detail/id/5497184/

                  Перевод книги, которая станет классикой
                    0
                    О, такой еще не читал, спасибо, ознакомлюсь. Особливо нравится картина Кандинского на обложке, очень в тему.
                  +11
                  Наступая на грабли выявил такую закономерность (поправьте если что). В идеале:

                  Model — Все объекты и вся бизнес логика. Включая «простые» методы (например getProductName(), purchaseProduct(), т.е. всё что НЕ зависит от пользователя, делает требуемое действие без проверок на есть ли право и т.д.) так и «сложных», типа purchaseProductWithUserDiscountAndSendMail(). Никаких конфигов внутри, все передается параметрами. Всё для того чтобы был прозрачен интерфейс и легко тестирование.

                  View — только логика вывода (foreach, if...else, порой и сложная логика) тех данных что переданы в него. Результатом может быть HTML, или XML, или PDF, только что-то одно. Выбрасывается с новым дизайном, как шкура змеи.

                  Controller — нечто что знает всё об окружении (платформа, пользователь, устройство ввода) и передает данные от пользователя к модели и генерирует данные для View. Также инициирует нужные объекты модели, формы. Очень зависит от конфига (в основном передает значения в аргументах модели). Нельзя сказать что в контроллере нет бизнес логики, хотя логика здесь «управленческая».

                  В итоге модель это готовое API, всё тестируется. Контроллер — платформенный мусор, View — верстальщицкий мусор. Дальнейшее разделение (View на Renderer+Templater) по желанию и потребностям.
                    –1
                    Вообще все совпало со статьей, ИМХО. Меня всегда коробило от того, что в одних и тех же классах программисты смешивают предметную область и, как Вы правильно заметили, «платформенный мусор». Класс должен относиться или к реальному миру или к технологиям, именно это нужно разделять.
                    +2
                    Я думал о том же с момента моего ухода с delphi и природа только недавно подарила мне решение которое помогло мне. Это GWT и GWT MVP фреймворки. Как следствие:

                    > при полном отказе от HTML и сведении страницы к одному тегу подключения JavaScript

                    Именно так, клиентское приложение по сути вызов одного JavaScript'а.
                    Учитывая что я разрабатываю именно Web приложения и у меня нет необходимости в том, чтобы мое конечное приложение корректно индексировалось поисковиками. Таким образом клиентский код и код среднего звена у меня разделены. Это неплохо разгружает среднее звено и позволяет обслуживать больше клиентов.
                    > Storage-Model-Application-Renderer-Template-Model
                    Я считаю, что в вашем случае GWT MVP позволит избавиться от уровней: Storage, Application, Renderer и Template. И двух моделей — так как GWT позволяет иметь один и тот же Model как на клиента так и на сервере, для передачи используется GWT RPC.

                    MVP фреймворк отличается тем, что пользователь взаимодействует с конечным View который выстреливает евенты которые обрабатывает Presenter который оперирует с Model и если есть необходимость c View.
                    Вообще различие между MVP и MVC хорошо проиллюстрировавший на рисунке:
                    image
                    Как видно MVP более последователен, как следствие меньше разночтений.
                      +1
                      Интересная картинка. Из того что понял я ( а я изучаю этот вопрос недавно) основная задача MVC максимально выделить шаблоны отображения, чтобы озадачить работой много дизайнеров и иметь выбор тем. Если брать какие нибудь типовые сайты, или софт типа интернет магазинов, то мы обычно имеем один блок логики приложения, и сотни вариантов визуализации.

                      MVP довольно сильно усложняет вышеописанную задачу, поскольку View становится полноценным блоком кода. Этот подход приемлем для озадачивания работой кучи программистов в каком нибудь бизнес-ориентированном проекте где наоборот дизайн остается постоянным, а бизнес-логика гибко расширяется и изменяется.
                        +1
                        Вообще, я поднял этот вопрос чтобы показать, что есть разные точки зрения и MVC — это не монолит, а просто направление, в котором все двигаются по-разному. Ну и конечно, выбор или создание архитектуры диктуется задачей, нет решений на все случаи жизни, как бы не хотелось их заполучить.
                          0
                          На самом деле никто и ничего не усложняет выбор того или иного патерна вопрос скорее религиозный.
                          И часто сделать выбор программисту помогает фреймворк. если вы используете java то там MVP проповедуют: Swing, JFaces, GWT и Vaadin.
                          Так как я использую GWT, Google сделал выбор за меня. И естественно google лоббирует выбранный им Pattern.
                          Привожу ссылку на презентацию, поискав по ключевому слову
                          «Decoupling via MVP» можно найти часть презентации посвященной именно паттернам.

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

                          Так что я считаю MVP ничего не усложняет при условии 1 View и 1 Контроллера кол-во строк кода будет неизменным. А вот при увеличении кол-ва View считаю MVP более удачной моделью.

                        +3
                        За последние две недели, в беседах с десятком знакомых программистов я выяснил, что все представляют себе MVC совершенно по-разному. Доходит до диаметрально противоположных взглядов,
                        Я общаюсь с разными программистами уже больше 10 лет и каждый из них видит MVC по своему, и Вы правы — даже противоположные взгляды. Надо понимать, что MVC — это парадигма, а не догма. И по этому каждый из них по своему прав.

                        Существует первый взгляд на MVC В WEB есть свои адаптации, и их несколько видов…

                        В целос статья мне понравилась,
                        спасибо, многим будет полезно.
                          +3
                          Все источники утверждают, что MVC пришел из smalltalk. Думаю первый взгляд надо искать там. :)
                          0
                          Сейчас мы с товарищем доделываем один проект, начатый с нуля. Так вот, в начале мы приняли решение взять за основу MVC с целью разделить представление, данные и логику. Т.к. опыта мало, мы натыкались на различные грабли, было желание всё глобально переписать/перепроектировать, создать еще с десяток классов для чего-нибудь…

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

                          Это я к тому, что понимание MVC у всех не только разное, но и некое «универсальное понимание» особо не нужно.
                            +5
                            В статье упоминается модель MVVM, но мне кажется, что это не совсем точное описание и применение данной модели. Более того, я считаю одна из проблем использования MVC кроется как раз в отсутствии MVVM.
                            MVVM — Model — View — ViewModel — это патерн, такой же как патерн MVC и совместное использование этих патернов в большинстве случаев дает хорошие результаты. Если кратко, то MVVM служит для решение следующий проблемы. У вас есть бизнес модель, построенная по результатам анализа, и она нормализована и адекватна, т.е. не должна содержать дублирования данных и полностью отражать бизнес сущности. Однако, если вы берете эту модель как есть, и пытаетесь вставить ее в представление вы получаете интерфейс, который не соответствует логике пользователя и юзабилити. В итоге мы имеем интерфейс к базе данных — в лучших традициях Дельфи и Фокспро. И это не очень хорошо с точки зрения пользователя.

                            Т.е. бизнес логика или логика системы — это одно, а логика представления это немного другое, и модели у них не всегда совпадают. Для этих целей как раз и используют ViewModel.

                            Ну и конечно, что MVC, что MVVM, Repository, UnitOfWork etc. это всего лишь патерны, и использовать их нужно осмысленно, понимая, для чего ты это делаешь, исходя из задачи.
                              0
                              Я предлагаю посмотреть на SpringMVC. Там в reference есть примеры, и в моем понимании MVC там реализован хорошо, а именно:
                              — Model — это чисто POJO (как Command bean, так и просто DTO для view)
                              — Controller — то что, заполняет модель или считывает с нее данные и делает с ними, что требуется (а именно передает на сервисный уровень, где происходит нужна бизнес логика)
                              — View — то что показывает модель

                              Ничего лишнего, и четкое разделение по зонам ответственности.
                                0
                                Вот именно POJO и невозможно пользоваться — хороших 75% аппов — это тупой «pass-through» в бакенд. Нафиг вообще objects? Именно поэтому все вцепились в скаффолдинг
                                +1
                                Самое основное заблуждение, что люди считают MVC чем-то законченным, а не парадигмой, это всего лишь советы, а не требования. И соответственно взгляды могут отличаться.
                                  +2
                                  Рассматривайте вид как шаблонизатор. В нём не объявляется новых переменных и он может работать только с уже переданными данными.
                                  Модель хранит всю информацию о данных. Включая, например, правила валидации и SQL.
                                  Но вся логика и операции происходят в контроллерах. Например, сама валидация данных в соответствии с моделью.
                                  Контроллер будет ядром системы и не будет захламлён, например, SQL-запросами.

                                  Что лично я встречал чаще всего — это то, что программисты внезапно переходят от MVC к привычному им подходу. Без предупреждения, просто начинают клепать какие-то уберклассы, которые объявлены как модели, но вместе с тем работают как контроллеры и ещё умудряются управлять представлением данных. Вот это — реально проблема. А различные трактовки MVC всегда можно согласовать.
                                  • UFO just landed and posted this here
                                    • UFO just landed and posted this here
                                        0
                                        А у меня как-то наоборот — при рефакторинге «плоского» PHP-спагетти MVC вырисовывается сама, без целенаправленных усилий с моей стороны, фактически только следуя принципам типа DRY и SOLID.
                                        +2
                                        Статья хорошая, но попытка придумать свой mvc — бессмысленная. из паттерна нужно вынести только главную идею — разделяй и властвуй, плевать как называются слои, главное чтобы они были максимально независимыми и легко заменяемыми.
                                          –1
                                          и еще чтоб летало на нагрузках…
                                            0
                                            реальные нагрузки встречаются очень-очень редко редко. а оптимизация под нагрузки как раз легко должна решаться заменой сдлоя на более оптимизированный (в начале проекта стоит отдавать предпочтение скорости разработки и поддержки).
                                            собственно для этого весь этот слоёный пирог и нужен, а то линейный код иногда писать в разы проще и быстрее по началу.
                                              +1
                                              >реальные нагрузки встречаются очень-очень редко редко
                                              мой предшественник так наколбасил с иерархией категорий,
                                              что в реальных условиях сервер умирает на таймауте…
                                          0
                                          О, еще по теме очень советую прочесть вот что:
                                          Pádraic Brady
                                          «The M in MVC: Why Models are Misunderstood and Unappreciated»
                                          blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/
                                            +1
                                            Дык, MVC — это только паттерн, а не архитектура. Архитектура каждого отдельного MVC-фреймворка может отличаться очень сильно, но при этом быть MVC (или его разновидностью, HMVC, MVP, MVVM и прочие «MV»).

                                            Сегодня MVC стал популярен в основном благодаря применению для веба — и большинство из появившихся фреймворков — реализация MVC в виде архитектурного паттерна Front Controller. Очевидно, что это только один из вариантов использования MVC, более того, в очень конкретном контексте (веб, принимая во внимание HTTP и его особенности и прочее).
                                              0
                                              Да, но MVC это скорее архитектурный паттерн, чем паттерн ООП или программирования вообще. MVC можно реализовать вообще даже на bash или на си. А при реализации Front Controller (единая точка входа) в веб-сайтах и веб-приложениях, MVC сам напрашивается. Посмотрим, какие решения принесут нам следующие 2-3 года, ведь скоро во всех браузерах (включая мобильные девайсы) будут доступны хорошие веб-сокеты с постоянным TCP коннектом и можно будет писать полноценные клиент-серверные протоколы, без AJAX/JSON и Comet (Long-Pooling). Думаю, это несколько изменит архитектурный мейнстрим в вебе.
                                                +1
                                                Верно, MVC — архитектурный паттерн, но очень-очень общий. Он ничего не говорит о конкретном окружении и контексте. А Front Controller — это очень конкретный частный случай. Ну, собственно, я вижу, мы говорим об одном и том же. Я просто написал это к теме топика — ибо многие путают именно «MVC как таковой» с Front Controller-ом.
                                                  0
                                                  Насчет ближайших перспектив — не уверен, что что-то очень уж сильно поменяется. Ведь и сейчас в целой куче проектов бывает удобнее даже для толстых клиентов обращаться к сервисам через HTTP. Для сокетов, безусловно будут свои задачи, но вряд ли с их повсеместным появлениям куда-то уйдет старый добрый stateless-http.

                                                  Впрочем, конечно, я бы не загадывал однозначно, ибо неизвестно. Известно одно — веб будет развиваться дальше и очень стремительно.
                                                    +1
                                                    В HTML5 мы получаем SQL-совместимую СУБД, и полноценные сокеты, а на сервере, все к тому идет, что мы получим stale-full серверное приложение на node.js или же просто сохраняющее состояние в memcached или в др. месте. Конечно же, это нужно только для приложений, а stateless остается для сайтов и веб-страниц, там состояние не нужно совершенно. Прикладным же приложениям без машины состояний ни как нельзя, состояние нужно и в UI и в сервере приложений, ну а в БД оно есть само собой.
                                                      +1
                                                      Что дает хранение состояния и сокеты (просто мысли в слух, это все очевидно):
                                                      — Приложение может жить без постоянных запросов к серверу достаточно продолжительное время, исполнять свою логику, сохранять в локальную базу и не бояться потери данных;
                                                      — Возможность не перегружать страницу;
                                                      — Минимизация трафика;
                                                      — Возможность синхронизировать экраны у пользователей;
                                                      — Возможность управлять экраном браузера с сервера (не заменимо в приложениях групповой работы и играх);
                                                      — Возможность работы в оффлайне;
                                                      — Возможность транслировать события в две стороны между моделью, развернутой в браузере и в памяти на сервере.
                                                        +1
                                                        Ну это только одни из кучи сценариев.

                                                        «Приложение может жить без постоянных запросов к серверу достаточно продолжительное время, исполнять свою логику, сохранять в локальную базу и не бояться потери данных»
                                                        Зависит от того, какие данные — если настройки, данные текущей сессии — да, но если данные, меняющие общее состояние системы — это целая задача все правильно синхронизировать. Вообще, «проблема Stale-Data» — большая и обширная тема :)

                                                        «Возможность управлять экраном браузера с сервера (не заменимо в приложениях групповой работы и играх)»
                                                        Это бы круто, да.
                                                          0
                                                          У меня сейчас как раз заканчивается разработка одного приложения, где пользовательским экраном управляет сервер напрямую, то есть, поток команд льется через Comet (Long-pooling) и каждая команда интерпретируется и исполняется джаваскриптом на клиенте. Это как в X-Window System в *nix системах. Красота, в общем. Но я бы с большим удовольствием использовал сокеты, чем Long-pooling. Кстати, как раз в этой задаче стоит вопрос о локальном хранении состояния, т.к. браузеры могут отваливаться и быть в оффлайне (работают по wi-fi и мобильному инету). Тогда конечно поток команд с сервера прекращается, но события происходят, и при восстановлении соединения, нужно все это отдавать серверу. При этом, пользователю будет очень обидно, если события потеряются, а такое сейчас случается, если при пропадании связи он жмет рефреш.
                                                            0
                                                            Интересная тема.

                                                            Пара вопросов:
                                                            — А что за приложение, если не секрет?
                                                            — Чем обусловлено такое явное предпочтение сокетов, нежели Comet?
                                                              0
                                                              Проект: телевизионная тема, идея — синхронизировать браузер с телеэкраном, более подробно не могу открыть, к сожалению. Ну сделано то на комете конечно сейчас, но будет постепенно переезжать на сокеты. По многим причинам: комет вводит браузер в состояние загрузки страницы, это много на что влияет, например, во многих браузерах крутится бублик, а чтобы не крутился, нужно делать комет в айфрейме — это уже заплаты. Еще: комет держит на сервере процесс специально под соединение, а у меня десятки тысяч пользователей. Если делать на сокетах, то такого не будет, сервер можно будет сделать на C#, Java, Node.js или др. и это будет один процесс серверный и в нем просто много сокетов открыто, а логика в памяти на них на все один раз развернута (автор тяжко вздыхает, вспоминая о Delphi). Ну и сокеты — это двухсторонний обмен, т.е. и клиент может присылать пакеты и сервер, можно синхронно, а можно и асинхронно, как в моем случае и нужно.
                                                          0
                                                          Как-то мне кажется, что очень многие веб-приложения рассчитаны либо взаимодействие пользователей в реал-тайме, либо на возможность пользователю получить доступ к своим данным с разных девайсов. Тут локальное хранилище и сокеты обеспечит по сути только инкрементальную синхронизацию локальных и серверных данных в том числе по инициативе сервера.
                                                    +1
                                                    Вопрос вот в чем — в какой срок ваш подход позволит поднять систему с «нуля»?
                                                    Я не знаю ни одного комплексного подхода реализованного на уровне «outofthebox».
                                                    Тот, кто восхваляет Hibernate или смакует MVC с LINQtoSql, должны себя спросить — могут ли они сделать «бизнесс форму» с форен ключами и.т.д. за 20 минут. Delphi, кстати, почти был основан на view model (tfield, tfielddef) и, как результат, многие задачи решались проще чем в современных «чистых» frameworks.
                                                      0
                                                      Ну прогресса в современных средствах разработки не видно ни для разработчика, ни для конечного пользователя. Мощности растут, а вот программисту создать или пользователю заполнить простую форму, к примеру, в современных технологиях дольше сейчас, чем это было в консольных программах, когда еще все псевдографикой рисовали и мышку не использовали. Сейчас разработчик, к сожалению, погружен в концептуальные подходы, паттерны и изобретательство, вместо того, чтобы думать только о предметной области, о поставленных задачах. Это говорит о том, что технологии сырые и зеленые еще, «outofthebox» для прикладных приложений нету, а даже если кто-то себя так и позиционирует, то это системы узко специализированные (типа CMS, CRM, SCM, BPM, документооборот и бухгалтерия), а вот именно прикладных платформ нет и не предвидится. Корпорации заняты войнами технологий, а их можно выиграть только внедряя что-то массовое и не оставляя конкурентам надежды на интеграцию и стабильность. Вот и видим только ПО массового потребления, коммуникационное, офисное, системное, работающее с информацией на уровне файлов и не углубляющееся в прикладные базы данных. Развитие прикладного ПО, как мне кажется, вообще пришлось на 1999-2003 годы, после этого оно стало вялотекущим из-за проблем с инструментарием и из-за заложенных во имеющиеся платформы ограничений. Сейчас вот веб-приложения начали понемногу приближаться к формированию устойчивой среды из стандартов, подходов и средств, но она все еще очень разношерстна, и только в 2010 году наконец браузеры дали нам инструментарий который был доступен для оконных приложений (в том же Delphi) еще 10 лет назад.

                                                      Only users with full accounts can post comments. Log in, please.