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

не плохая — девичья :)

Жесткий пылесборник однако :)

Это другое дело, только NS+MP, как мне кажется, неэффективен :)

Эх, как я и сам это люблю. :) Единственный недостаток — так редко удается с ним работать!

По сути вашего вопроса:
XML действительно посредник, но сам по себе XML — это формат без какой либо определенной структуры. А это значит что вам следует ее определять самому. И донести это до всех, кто захочет с вашей структурой работать.
А SOAP — это стандарт известный всем :) И многие языки УЖЕ имеют инструментарий по сборке и разбору структуры его XML (что в примерах к статье и показано).

А сам принцип о котором вы говорите — больше из концепции REST, которая именно так все и упрощает (получил параметр — отдал ресурс). В рамках веб — это всем понятно.

А сам SOAP больше завязан на теории ООП и удаленного вызова процедур (манипулирование с удаленными объектами, неизвестно на чем написанными).

Посмотрите с другой стороны — предположите, что вам нужно сделать «склонятор» :)
Кроме того, современные инструменты позволяют не разбирать XML самому, если уж речь идет о клиенте.

Спасибо, обязательно внесу исправления в текст. Вы не против?

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

Ну в данном случае это больше проблема настройки веб-сервера, так как отдается просто статичный файл. Тем не менее имея полный доступ к серверу — поправил :) спасибо

Из тех же новостей:

1 января
В 2008 году Студия Лебедева значительно расширится.
…
5 декабря
В Студии Лебедева произошло 20-процентное сокращение — с 250 до 200 сотрудников.

Грустно. И так везде, к сожалению…

Вот как и обещал, мои мысли — приглашаю обсудить и внести коррективы:
mikhailstadnik.com/mvc-structures

Кстати, u в конструктори — это еще ошибка от Дэниэля :)

Вот она сила копи-паста :)

а, все понял уже :)

Безусловно, благодарю за замечания, только я не понял последний ваш пункт с массивами…

Проблема в том, что просто сравнить не всегда получится, например в случае bool, boolean и int, integer. Проблема в том, что PHP по сути имеет несколько алиасов для определения одно и того же типа — поэтому массив. А в принципе — я с вам согласен и тоже сначала так сделал. Потом столкнулся с описанным выше и все-таки ввел массив :)

> А вот это уже зависит строго от того, как делать. Например, разделять фронтэнд и бэкэнд вовсе не обязательно.

Совершенно верно :) Это можно разделять политикой прав. Я лишь привел банальный пример, понятный каждому. И все таки разные типы приложения так или иначе будут порождать разные контроллеры, так как у них как правило РАЗНОЕ ПРЕДНАЗНАЧЕНИЕ. (Консолное и веб-приложение будут решать разные задачи). Такое случается часто.

Вы меня натолкнули на идею статьи по архитектурам, за что вам отдельное спасибо :). Откланиваюсь.

> 'это не разные контроллеры, это разные View.'

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

> 'философию, не имеющую практических предпосылок'

Как раз наоборот. она вытекает из практики. Я очень хорошо понимаю вашу позицию, поверьте. А вы просто попробуйте выйти за ее рамки и, возможно, вы увидите смысл и в моей ;)

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

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

Позволю себе с вами поспорить. ИМХО, то о чем вы говорите — не грубое нарушене, а предпочтения разработчика все-таки. Моя позиция основывается вот на чем. Я несколько абстрагировался от концепции исключительно веб-приложения. По сути вы говорите о концепции MVC. Я же думаю о M-VC. Т.е. модель как бы в стороне от вью-контроллер. Веб-приложение — это лишь частный случай реализации интерфейсов и взаимодействия с пользователем программного комплекса. Но ведь никто не заставляет нас ограничиваться лишь вебом. В сложном проекте у вас могут быть различные VC, построенные на одной модели: веб-фронтенд, консольный клиент, сервис-приложения, GTK в конце-концов.

Вот пусть они лежат в папке application/. Т.е. там у нас вью-контроллеры. И папка модель там будет выглядеть несколько нелепо.

А значит, что с этой точки зрения, модель есть не что иное, как БИБЛИОТЕКА общих функций бизнес-логики для бесконечного набора вью-контроллеров. Поэтому я и предложил вынести ее в library/. И это всего лишь мое предпочтение, как разработчика, основанное на внутренней философии. Вы же в силах поменять структуру так как считаете нужным. А с формулировкой «грубое нарушение», простите, я не согласен.