Пипец... Мало того что область применения САПР не указана, так еще и поиском пользоваться не умеем. Из известных крупняков АСКОН, например, если вы занимаетесь САПР, то отечественных разработчиков должны знать в лицо. А если решаете одноразовую задачу, то правильнее спросить у своих инженеров.
WCF это инструмент, IMHO один из компонентов ESB, и предназначен для реализации подобного рода проектов. Инструмент не может быть основой архитектуры, так как он является инструментом для реализации той или иной архитектуры. И в частности ESB. В своем примере вы описали что-то весьма похожее на ESB (и мысли вполне здравые), поэтому я и высказался на предмет того, что "не по Сеньке шапка", предприятие должно "дорасти" до ESB в первую очередь организационно, и технологические попытки вытащить его (предприятие) на другой уровень обречены на провал. Для интереса посмотрите функционал и архитектуру ESB, например WSO2 (https://wso2.com/). Потом посмотрите, что предлагается на рынке ESB из Microsoft only way-решений.
P.S. И не привязывайтесь в архитектуре к инструментам, вы себя сразу сковываете набором возможных решений. Возможно что, что-то будет правильнее сделать даже не на компьютере ;-) Для иллюстрации, у Амазон есть грузовик специальный для миграции данных ;-)
Когда я учился программированию, то мы получали не больше тройки если объем комментариев был менее 60% кода. Это был входной фильтр, сначала по объему комментариев, затем по их содержимому :-)
По кусочку кода трудно понять общую картину. Но если это конечный автомат, то красивые примеры на php можно найти в И-нете.
Видимо не функцию, а ее вызов. Позволю себе догадаться, что это некий селектор операций который вызывает указанную функцию и передает ей некоторые параметры. Чтобы сделать вызов более понятным (понятие красоты кода у нас могут сильно различаться), я бы засунул все три параметра либо в массив, либо в экземпляр некоего класса и получилось бы что-то вроде
$fnresponse = myFn($proc->name, $proc->parameters, $proc->testcase)
Как и где формируется $proc это другой вопрос, как правило в чем-то обычно называемом фабрикой.
Вопрос был не про извращения ;-) ИМХО, а о том как это выразить средствами ООП PHP. Логика и назначение данного кода мне неизвестно. Однако большинство языков программирования отрабатывают выражения слева направо, учитывая скобки и приоритет операций, за исключением обратной польской записи.
Нет вызов идет слева направо myFn->declare->vars. vars не может быть первым хотя бы потому что экземпляра объекта с таким методом еще не существует, его вернет declare. Тоже самое можно сказать про declare - пока не отработает myFn экземпляра с методом declare еще не существует.
Хм... функцию в ООП? Это как вода в огне. Возможно автор имел ввиду "функционал средствами ООП". Правильно заданный вопрос 50% ответа. Почему-то об этом на тостере стали часто забывать.
Как вы обращаетесь в hibernate к коллекции, как делаете выборку? Это вопрос к вам, вы так и не указали что вы выбираете из базы и к чему пытаетесь обратиться. Если вы выбираете из базы user, то коллекции связанные с выборкой user загружены не будут, то есть совсем (это при lazy). Если вы из базы выбираете коллекцию, то user (при lazy) связанные с зарруженными даными коллекций тоже загружаться не будут до обращения к ним.
Хорошо, допустим вы обратились к коллекции, режим lazy, коллекция загрузится ровно в том объеме, в каком был сделан запрос. А вот соответствующая запись user грузится в этом режиме не будет, пока к ней не будет сделано явное обращение.
Вы прочитайте еще раз на что влияет lazy/eager - на загрузку зависимой таблицы при выборке из основной. На ваш вопрос невозможно ответить так как неизвестно в каком режиме идет обращение к основной таблице и есть ли оно вообще, какого рода зависимости в таблицах и как это отображается в код.
Ничего имхо не поменяется что lazy, что eager для зависимой таблицы рояли не играет. Вот если на таблицу user поставить lazy, то выбирая из user зависимвя коллекция будет загружена только когда к ней будет обращение.
Как упражнение для ума вполне подходит. Практическая ценность стремиться имхо к нулю. Такого рода жесткие бд видел только во встраиваемом ПО. Да и там используется SQLlite который и так лайт.
Кажется понимаю куда он клонит -
....Такой подход по идее снизит накладные расходы по сравнению с традиционными СУБД (на тот же парсинг SQL-запроса, на двойное копирование данных в сокет/общую память при передаче их между приложением и СУБД, на множество «лишних» проверок, неизбежных из-за универсальности традиционных СУБД). Плюс к этому логично предположить, что существенно ускорит производительность выпиливание всей...
А это не хранимые процедуры случайно? И кто сказал что SQL не кеширует запросы?
