Нахлобуча увеличение мажорной версии последующих релизов было, как мне кажется, по большей части продиктовано маркетинговыми соображениями, а не техническими.
Весь дотнет на версии 4.0 с Linq2Sql фактически закончился. Все остальное - свистоперделики, не более.
Вся борода с данными прекрасно распутывается на T-SQL без всяких абстракций над абстракциями. И никакими кешеми голову забивать не нужно, SQL Server прекрасно умеет кешировать. А Linq2Sql имеет все необходимое что бы наладить обмен данными со скулем. Вот и весь расклад. Смысл юзать EF есть только для работы с источниками данных отличными от SQL Server, а так он нах не вперся. ИМХО.

МСУНе понимаю ужаса. Пусть себе развивается EF, зачем ему мешать?
Ужас в том что многие ищут инструмент с кнопкой "сделать все", при этом не понимая, что если такой инструмент появится, то и разработчики нафиг не будут нужны. А в погоне за этой "кнопкой" тратят свое время соответственно и деньги. IT уже не то что 10 лет назад, действительно эффективные инструменты уже давно придуманы, вероятность что новая свистоперделка будет приносить офигенный профит стемится к нулю... селяви...

ViPRosEDUARD SAPOTSKI,

скл сервер хорошо работает
даешь ему в рожу запрос
он ли хавает или посылает нах
но хавает он обычно простое фуфло, а в жизни все не просто
потому приходится перед скл сервером построить специальные семантические трансляторы для перевода сложного в простое
эти трансляторы могут работать только на основе каких то моделей расширяющих модель скл сервера (РМД + коей какая мелочь)
такие гавнотики как хибернет, еф и т.д. претендуют на роль эту
но нифига не умеют
а когда оснзнали чт нифига не получится ушли в кусты
типа мы и не думали, мы просто пытались помочь убогим и сирым и т.д.
В общем то согласен, но не могли бы Вы привести пример:

ViPRosпотому приходится перед скл сервером построить специальные семантические трансляторы для перевода сложного в простое
Как-то никогда с такой проблемой не сталкивался, или недопонимаю о чем Вы...

ViPRosно всегда можно отложить и проанализировать характер команд и характер данных над которыми эти команды командуют :)
а если ты не работаешь предельно онлайн с блокировкой (а все эти ЕФ, Хиберы и т.д. - практически системы оффлайн репликации), то у тебя есть время и дополнительная инфа (из модели собвственной и скл) как разрешить коллизии, не свялвая все на прогера прикладной части
Чето нифига не понимаю что может дать анализ из собственной модели на клиете...
Я далаю так. Во первых, каждую атомарную операцию I/U/D сразу фиксирую на скуле. Да, запросов получается гораздо больше чем при обновлении скопом, но это оберегает от кучи коллизий.
Если юзер пытается обновить удаленную запись, сервак кидает эксепшн, юзеру показывается месседж - увы и ах, на клиент перезагружаю данные из этой таблицы и связанные с ней данные.
В каждой таблице в базе есть поле LastUpdate datetime. Юзер передает на сервак объект который хочет удалить, скуль смотрит, совпадает ли LastUpdate объекта с записью в базе, дальше действую по обстоятельствам...

skyANAEDUARD SAPOTSKIВся борода с данными прекрасно распутывается на T-SQL без всяких абстракций над абстракциями. И никакими кешеми голову забивать не нужно, SQL Server прекрасно умеет кешировать.Когда у тебя в пике 500 запросов в секунду, 10 серверов в ферме, помимо основного хранилища, есть ещё и NoSQL, то "вся борода с данными прекрасно распутывается на T-SQL... никакими кешеми голову забивать не нужно...", ну-ну.

Пеши есчо
Более фееричного бреда не слышал
Те нада ферма из 10 серверов что бы 500 запросов в секунду разрулить? Пацталом!
Расскажи это телекомовцам или банкирам, они поржать с утра просили

ViPRosну я ж грил тебе, что если неработаешь в реалтайм режиме - когда каждый чих суется в БД, а другие читают это незаконченное говно и выдают на отчет
этот способ нас не интересует
А другие способы перерастают в головняк, разрулить который крайне проблематично а порой впринципе не реально.

ViPRosхаха
преставлю -
Эдурд - вводить Шапку накладной и тут же сохраняет
Триггер - тут же удаляет Шапку без строк
:)
скоко это будет продолжаться?
пока Эдуард не введет хотя бы одну строку
ну тут уже кеш!!! и Эдурду надо думать, а какую запись сохранить первой, а какую второй очереди в тразакции
дальше больше, а вдруг надо замениь или удалить
тут уже топологическая сортировка
дальше еще хуже
надо надо топологию эт разбить в зависимости от типов консрейнтов и т.д.
пока Эдуард не дойдет до того что бы (а может сразу и дошел) а нафига мне эти фоинкеи контсрейнт ыи т.д.
не лучше ли в мусоре копаться :)
ты друг не прогу пишешь, а игрушку и даже не однопользовательскую, а одностроную:)
без обид

вот МС начал с табле адаптера с одной командой Update
потом повяились и insert delete и куча других на уровне таблицы
потом на уровне записи
потом появился таблеадаптерманаджер с иерархией
нифига опять не получиась и вывели на прогера Ордер типа сам выбирай
а прогер то и рад да не всегда может
плюнули на датасет - типа слишком рыхлая модель маппинга и давай сделаем ЕФ где мы управлем со структурой БД или со структурой объектов в кеше
иии приши к адаптерам и тем же сортировкам и тем же гавнистым рещшениям
решил обогатитть скл сервер с ченйндж треин и дата каптуре
и все равно нихуа и теперь пишут без "абстракций" т.е. без МОДЕЛИ ев 7.0
а народ усмехается
ух ты блин скоко написал
Да я кагбэ и согласен, но, по такой примитивной методе как я предложил работет большинство ACID систем. Но мне больше интересно что ты предлагаешь? Грить что кругом все херово не трудно. Лично я в мусоре уже накопался, больше не хочу. Сейчас все что можно засунуть на скуль - засовываю, минимум логики на сервере приложений и еще меньше на клиенте и пока вижу в этом подходе существенный практический профит. Собственно в чем смысл твоего посыла никак догнать не могу, может просветишь?

skyANAа в каком конкретно телекоме кстати "вся борода с данными прекрасно распутывается на T-SQL"?
Я не говорил что в телекоме T-SQL, в основном оракл юзают, но суть да дело это не меняет. Знаю двух операторов мобильной связи у которых основная логика крутится на PL/SQL и одного оператора "наземных" телекомуникаций у которого много технологий в том числе и SQL Server. Но поименно называть не буду.

skyANAто есть на поверку выходит не вся борода, а только основная часть
Ну КэП подсказывает что SMS-ки шлет базовая станция а не PL/SQL(T-SQL), а денюшка за SMS-ки списывается на уровне СУБД.
Так что да, ты прав.