love via soap II: php + c#

Часть 1, в которой рассказывалось, зачем это всё нужно, и как несложно реализуется взаимодействие  php-клиента с asmx-сервисом.

В этой части мы будем писать SOAP-сервис на php, а клиентскую часть - на C#.Так что пристегнись, это php!

Микромир ORM на примере Massive

В мире больших и тяжеловесных ORM-решений, таких как NHibernate и Entity Framework, вполне предсказуемым стало появление течения микро-ORM: легковесных прослоек между БД и объектами приложения. Чем хороши microORM? Прежде всего, скоростью выполнения запросов: она сопоставима со скоростью чистых запросов через SqlDataReader. Потом - микро размерами: например, Massive - это всего лишь один подключаемый файл на 673 строки кода, в отличие от NHibernate или EF, которые тянут за собой целую dll-ку на несколько сот килобайт.  Наиболее известные из micro ORM:

1) Dapper, разработанный и активно использующийся в StackOverflow и StackExchange
2) Massive, разработанный Rob Conery, пример использования - HanselMinutes
3) PetaPOCO

Massive - это лучше, чем шоколад

Основа Massive - это dynamic-типы, появившиеся в .NET 4.0. Чтобы понять, что такое Massive, как и зачем он появился на свет, посмотриет видео  "Kill your ORM" с выступления Роба Конери на NDC 2011. А чтобы понять, насколько Massive лучше шоколада,  давайте напишем небольшое тестовое приложение, выводящее план счетов из БД в сгруппированом виде.

3 js-фреймворка на личном опыте

Разрабатывая веб-приложение (не путать с веб-сайтом с интерактивным UI) на jQuery, Zepto или другом UI-ном фреймворке, довольно быстро приходишь к изобретению MV*-велосипеда, сначала  отделяя данные от UI-части приложения, а потом назначая ответственного за взаимодействием между ними. Резонный вопрос: а какие существуют готовые решения, облегчающие взаимодействие UI, данных и логики, поверх jQuery (Zepto)? И как ответ недавно мне попалась статья "A Collection Of Javascript MVC Frameworks That You Should Know About". Знаете, сколько там фреймворков? Больше 30! Как же сделать правильный выбор? Выбор фреймворка - это серьезное решение, от которого не последним образом зависит будущее проекта. На решение каких проблем большим образом ориентирован фреймворк? Какой из MV* подходов используется во фреймворке (и стоит ли на этом заморачиваться)? Сильно ли тяжеловесен фреймворк? Сколько дополнительных библиотек он тянет за собой? Насколько быстро и легко разобраться с устройством фреймворка? Насколько хороша документация? Есть ли дружное сообщество вокруг библиотеки? Как не ошибиться, ведь все фреймворки похожи друг на друга, и каждый обещает сделать всю работу за меня? Да никак. Есть лишь несколько подсказок и советов от умудрённых опытом людей и сделанные на основе собственного опыта выводы.

Философия AMD, RequireJs и модульная разработка веб-приложений на JavaScript

Разделяй и влавствуй - подход на все времена. Концепция модульного программирования не нова, и хорошо себя зарекомендовала. В мире разработки web-приложений на JavaScript существует подход Asynchronous Module Definition или AMD, который

specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded [1]

т.е. по сути определяет API, следуя которому можно реализовать асинхронную загрузку самих модулей и их зависимостей. Следуя этому подходу, непроизвольно создаешь более элегантные решения, но это всего лишь бонусный побочный эффект. Главное - уменьшается хаос js-кода, сложность разработки и поддержки приложения. Каждый модуль явно указывает свои зависимости и получает только их, работая изолированно, что означает минимум мусора глобальной области видимости.
Всё, что нужно, чтобы начать использовать AMD подход в проекте, - это загрузчик, который знает, что такое AMD-модуль, и умеет подгружать зависимости.  Итак,