Здравствуйте, Elderos, Вы писали:

E>Глава "Доступ к данным"
E>1) Пишете про LINQ to Entities, имя в виду Entity Framework. Это разные вещи.
LINQ to Entities поддерживает LINQ-запросы к EF. Имелась ввиду именно эта связка. Безусловно, нужно это пояснить в следующей версии статьи.
E>2) Один из главных бонусов всяких ORM — это проверка корректности работы кода на этапе компиляции. В случае с ADO.NET это невозможно, а Entity Framework генерит слой, где трудно ошибиться.
E>4) Большинство ORM не только генерят неоптимальные запросы, но и дают значительный оверхед на вызов запроса
Полностью согласен, включу это в следующую версию статьи.
E>3) Незаслуженно забыты NHibernate и BlToolkit
К сожалению, не имел опыта работы с этими ОРМ, поэтому сравнивать не могу.
E>5) Ну и я бы не хоронил ADO.NET, у меня например совершенно противоположный опыт, и тяжеловесные ORM'ы в моих задачах скорее мешают, чем помогают.
Однако возрастает время разработки продукта — нужно писать много доп. кода. Тут все зависит от задачи — либо нужно сделать быстро, либо чтобы работало быстро. Зачастую требуется именно первый вариант.
E>Глава "Веб-сервисы"
E>1) Классы, которые генерит Entity Framework, сериализуются через DataContract
Собственно, я об этом написал
E>2) Передача данных в двоичном виде не затрудняет их кражу, кражу затрудняет шифрование
Однако, в отличие от текста, который читаем сразу, двоичный код нужно еще преобразовать в читаемый формат. Трудность мизерная, но она есть.

E>"Клиент на основе Silverlight" — было бы интересно почитать про различия в контролах популярных производителей и сравнение их со стандартными
Согласен, я думаю рассказать поподробнее про контролы разных производителей в следующей версии.

E>"Особенности разработки баз данных" — вообще непонятно, к чему это. Тема холиварная, а у ORM'а есть настройки по плюрализации имен
Этот раздел показывает преимущества SQL Server. Плюрализация имен работает отвратительно, если таблица названа множественным числом.