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

R>-использование неюникодных строк это ахтунг, несерьезно, вызывает желание закрыть и дальше не смотреть

Юникодные строки к данному дему отношение имеют весьма опосредованное. При необходимости элементарно конфигурируются.

R>-использование scope_identity вместо Output inserted — примерно того же уровня

Не вижу принципиальной разницы, хотя сделать не сложно. Для DB2 используется похожий механизм. Кроме того, есть желание это расширить до полноценного output.

R>-выбор adhoc vs parameter крайне неочевиден, но что он есть — очень хорошо
R>-merge выглядит очень сложно

Всмысле? Сложен Merge или InsertOrUpdate?

R>-поддержка DDL вообще никак не заинтересовала

DDL нужен в основном для работы с времеными таблицами. А так да, я лично предпочитаю база данных фёст.

IT>Юникодные строки к данному дему отношение имеют весьма опосредованное.
Использование неюникодных строк — грубая ошибка, ваша дема тупо не будет работать на кириллице
наглядный пример


IT>Не вижу принципиальной разницы, хотя сделать не сложно.
вставьте 10 Записей с получением их идентити, так понятнее?

IT>Всмысле? Сложен Merge или InsertOrUpdate?
InsertOrUpdate этот пример вообще какой-то странный весь из себя
Очень странно что автоматом выбрано мердж on id, если я PK знаю на кой черт вообще нужен insertOrUpdate а не просто update?
Ну ладно, пускай будет ид, но зачем блин два раза тупл писать ? пока там 1,5 колонки это не проблема, но в реальности-то их будет штук 10
Проще должно быть, что-нибудь в духе
InsertOrUpdate( new TestTable { id =1, Name = "Bla-bla" } ).On( Id )

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

IT>>Юникодные строки к данному дему отношение имеют весьма опосредованное.
R>Использование неюникодных строк — грубая ошибка, ваша дема тупо не будет работать на кириллице

Ещё раз. Моя дема не домонстрирует работу с юникодом вообще. Если нужна дема по демонстрации юникода, то её тоже можно сделать и продемонстрирвоать работу хоть с кирилицей, хоть с китаецей, хоть с японицей. Что касается грубости подобных ошибок как вообще, так и в частности, то это дело пользователя инструмента, а не самого инструмента. Молоток и плоскогубцы не должны учить мастера как и что он должен мастерить. Если инструмент навязывает пользователю обязательное использование юникода, то такому инструменту место на помойке.

IT>>Не вижу принципиальной разницы, хотя сделать не сложно.
R>вставьте 10 Записей с получением их идентити, так понятнее?

В linq2db пока нет методов, позволяющих вставлять 10 записей с получением их identity. Когда такой метод появится, тогда output станет актуальным. А пока не вижу принципиальной разницы. Так понятней?

IT>>Всмысле? Сложен Merge или InsertOrUpdate?
R>InsertOrUpdate этот пример вообще какой-то странный весь из себя
R>Очень странно что автоматом выбрано мердж on id, если я PK знаю на кой черт вообще нужен insertOrUpdate а не просто update?
R>Ну ладно, пускай будет ид, но зачем блин два раза тупл писать ? пока там 1,5 колонки это не проблема, но в реальности-то их будет штук 10

Потому что при Insert и Update может понадобиться разный набор колонок или разные значения. Впрочем, при желании можно написать overload с общим списком полей для Inser и Update и по списку по одтельности. Всё в наших руках.

R>Проще должно быть, что-нибудь в духе
R> InsertOrUpdate( new TestTable { id =1, Name = "Bla-bla" } ).On( Id )

Это называется InsertOrReplace, есть в той же деме.

Очередные подробности про EF7. Похоже, что изменится реально много.

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

Q>Очередные подробности про EF7. Похоже, что изменится реально много.

Если это главное что они собираются поменять в EF7, то как я и предполагал ранее, ребята явно сконцентрировались не на том. Правильный подход на самом деле может быть только один — Database First. Всё остальное годится исключиетльно для демок. В более менее серьёзных проектах остальные подходы не живут. Зато реализация этих подходов потребует серьёзных ресурсов, что приведёт к тому, что действительно нужные вещи будут задвинуты куда-ниубдь в угол, про них забудут, на них не хватит времени, опять прощёлкают их архитектуру и дизайн и опять всё поменяют в EF8.

В общем, ребятам нужно для начала годик поработать в Microsoft Consulting Services на реальных проектах клиентов с тотальным использованием EF, послушать маты в свой адрес и понять, что пора уже заканчивать заниматься фигней.

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

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

Q>>Очередные подробности про EF7. Похоже, что изменится реально много.

IT>Если это главное что они собираются поменять в EF7, то как я и предполагал ранее, ребята явно сконцентрировались не на том. Правильный подход на самом деле может быть только один — Database First. Всё остальное годится исключиетльно для демок. В более менее серьёзных проектах остальные подходы не живут. Зато реализация этих подходов потребует серьёзных ресурсов, что приведёт к тому, что действительно нужные вещи будут задвинуты куда-ниубдь в угол, про них забудут, на них не хватит времени, опять прощёлкают их архитектуру и дизайн и опять всё поменяют в EF8.

МС сейчас сконцентрирован на сайтиках и мобилках. Enterprise разработка, увы, не развивается вообще. Примерно за два года почти ничего не появилось для построения масштабных бизнес-систем.
Я узнавал почему так, ответ простой — это не продает облако.

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

IT>Если это главное что они собираются поменять в EF7, то как я и предполагал ранее, ребята явно сконцентрировались не на том.
Ну, рано загадывать на чем они сконцентрировались, пока это все дешевый популизм — пытаются успокоить недовольных переделками. Но вот пассаж про то что CodeFirst это вовсе не то, что мы имели ввиду — это красиво )

IT> нужные вещи будут задвинуты куда-ниубдь в угол, про них забудут, на них не хватит времени, опять прощёлкают их архитектуру и дизайн и опять всё поменяют в EF8.
Хорошо, если в EF8, чтобы осознать, что получилось фигня в прошлый раз, им понадобилось не меньше трех версий.

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

IT>Правильный подход на самом деле может быть только один — Database First.

Собственно в посте по ссылке и говорится, что Code First это Database First и Model First в одном лице.

rather than a third alternative to Database & Model First, Code First is really an alternative to the EDMX file format. Conceptually, Code First supports both the Database First and Model First workflows.

Причем, в таком варианте можно было его использовать еще с EF5 кажется. Были Reverse Engineering tools (хоть и бета но вполне работоспособные) для создания моделей и контекста по существующей БД.

IT>Всё остальное годится исключиетльно для демок.

Ну небольшие проекты (в стиле сайта для небольшой фирмы с каталогом) тоже вполне работоспособны и создаются быстрее на "классическом" CodeFirst. А вот чуть-чуть сложное и тут да, игнорировать возможности БД уже глупо, да и не всегда вообще получится.