Захабрился

Автор: -
Но я сразу себе сказал - не буду вступать в дискуссии, обсуждать, защищать, объяснять, хотя руки чешутся...

Комментарии

  1. Aleks22 октября 2011 г. в 23:12

    http://habrahabr.ru/blogs/webdev/117791/

    Интересная статья - я примерно к такому же выводу по организации приложения пришёл: MVC в базе, "тонкий" сервер приложений со своим MVC и клиент - со своим, при этом модель транслируется по звеньям в клиент (вид старшего уровня -> модель младшего), а контроллер, соответственно, - поднимает уровень исполнения по уровням, на каждом сверяясь с моделью на предмет возможности модификации, разгружая таким образом канал и базу.

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

    А как Вы оцениваете этот вопрос?

    ОтветитьУдалить
  2. Анонимный21 февраля 2012 г. в 12:27

    Ну, он же сказал: "не буду вступать в дискуссии, объяснять..."

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

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Введение мета-уровеня

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

Метамодель в задачах интеграции информационных систем

Автор: -
Изображение
Т.Г. Шемсединов УДК 004.9 Введение В последнее время, в начале разработки любой прикладной информационной системы, вопрос интеграции в уже имеющуюся сложную инфраструктуру предприятия стоит острее, чем даже вопрос функционала и производительности. Интеграция стала одним из основных факторов успеха в любой сфере бизнеса, а разработка превратилась из одноразового явления в постоянный процесс, в естественное состояние системы. Стало очевидно, что информационные системы двигаются от статической модели предметной области к динамической модели, изменяющейся в реальном времени. С другой стороны, распространение сетевых средств коммуникации позволило компаниям обмениваться информацией в цифровой форме с партнерами, клиентами, подрядчиками и даже государственными органами [1,2]. В таких условиях, старые методологии разработки, архитектуры, решения и технологии реализации нуждаются в серьезной модернизации. Постановка задачи Задачу интеграции информационных систем можно разбить на три составляю...
Далее...

REST и CRUD против RPC

Автор: -
Изображение
Развитие сетевых коммуникаций началось со специализированных протоколов, заточенных под прикладные нужды и повторяющих функциональность друг друга во многих случаях. Концепция эта называется RPC (Remote Procedure Call) или вызов удаленных процедур . Характеризуется RPC тем, что функциональность приложения полностью отображена в наборе команд протокола, например: FTP, POP, NNTP, протоколы СУБД, не говоря уже про многочисленные протоколы систем промышленной автоматизации или прикладных систем. Более поздние RPC стали абстрактными, т.е. появился некий стандарт, описывающий протокол, а уже на его основе разрабатывались прикладные службы, обладающие конкретным набором команд, например: SunRPC, DCOM, CORBA, Java RMI, и т.д. Следующий шаг заключался в ограничении набора команд до "универсального минимума" и перенесении всей смысловой нагрузки в параметры вызовов. Подход этот получил название CRUD по первым буквам команд ( create, read, update and delete ), а архитектура информацио...
Далее...