Разрешение конфликтов сильно зависит от предметной области, и чаще всего справиться с ним может только пользователь. Автоматическое слияние для случая изменения разных полей возможно, но часто не имеет смысла. Например, если в приложении со списком задач один пользователь меняет название задачи, а другой в тот же момент устанавливает флаг «выполнено», то при таком подходе в базе останется запись, не соответствующая действительности.
Лучшее, что можно сделать в этой ситуации — при возникновении конфликта сказать об этом пользователю, показать ему старую и новую записи и дать возможность разрешить конфликт.
Конечно можно использовать слово «замыкание» вместо слова «функция», но в данном случае если бы функции не были замыканиями, все бы работало точно так же.
Самодостаточен скорее разработчик Node.js — там все напоказ, зачастую приходится работать непосредственно c http запросами и ответами. Культура тестирования в Node.js-комьюнити очень развита.
Если приложение простое, и используются только стандартные средства, то, думаю, Yii будет выигрывать по скорости разработки и необходимому уровню знаний. Все таки Node.js требует хорошего понимания, что же происходит.
Нет, ничего подобного Yii, Symphony, RoR и т. д. — нет (по крайней мере, хоть сколько-нибудь популярного).Берется голый express и вперед — полная свобода действий. Для простых проектов это скорее плюс, потому что не нужно возиться с кучий конфигураций, сложной структурой папок и т.д.
Видел, что происходит про автоматической генерации кода в Java на основе Net овского WSDL — куча классов со странными именами и сильной вложенностью друг в друга, в итоге — практически ручная генерация сообщений, даже если сгенерированные классы работаю как надо, все равно нужно вытащить данные из своих классов и положить внутрь сгенерированных (потому как использовать их в своем коде невозможно).
В итоге при необходимости работать с SOAPом из iOS решил просто генерировать запросы из шаблона, подставляя нужные значения. Результат разбирать xpath ами. Из плюсов — надежно (вы точно знаете, что вы посылаете, какие нэймспэйсы, заголовки и т. д.), никакого сгенерированного кода, разбор ответов можно вынести в конструкторы соответствующих классов.
Просто относитесь к SOAP-службе, как к службе с xml интерфейсом, который придумал сумасшедший, а не как будто он соответствует какому то стадарту. Будет проще)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Лучшее, что можно сделать в этой ситуации — при возникновении конфликта сказать об этом пользователю, показать ему старую и новую записи и дать возможность разрешить конфликт.