МСУЯ ж тебе сказал, если у тебя DTO или что-то еще - все обновления через новый контекст. Что непонятно? ORM не будут работать с левыми классами.

да неужели? америку открыл просто, так проблема в том, чтоб заставить ORM работать с левыми классами, так как отображение идет в виде DTO, которое плоское, а обрабатывать надо Entity, которое с вложенными классами

МСУОткуда информация по утечкам? Где факты, а не сопли на голом сене?

факты были во время разработки и отладке метода, в виде окошка с экспешеном

МСУА причем тут EF? Во-вторых, длина запроса называется батчем. В-третьих, выше я тебе пальцем ткнул на 3 варианта, как сделать, чтобы непересвопить батч, мало?

я и не говорил что EF виноват, ошибку с длиной запроса выдавал MS SQL, читай внимательней

МСУДаже двоешники знают чудесные 3 буквы - SOA. Не сылхал? Срочно открывай букварь и начинай штудировать WCF и ASMX, а то так бездарем и помрешь.

xDDD а SOA/WCF - это что по твоему? не слой приложений/служб который 3-tier? мда...

МСУПричем тут протоколы с XML и ORM? Ты не вписываешься в повороты, заносит то влево то вправо.

при том, что было обсуждение 3-tier наряду с ORM

МСУНужно отрефрешить контекст, и чё дальше-то? Код я не пишу. Про несколько минут ты гонишь, разумеется.

разумеется не гоню, открыть дизайнер, нажать кнопку обновления контекста, выбрать там таблицу для обновления -> тупит порядочно, и занимает 2-3-5 минут

МСУДа какая в жопу разница, чья эта база. На девелоперских стендах также присутствуют данные, которые важны для отладки и тестирования, зачем их сносить?

ну не сноси, я тебе что запрещаю?

МСУВо-вторых, ты уже сам запутался, сначала говоришь про продакшен, теперь говоришь, что я опять не так понял, и речь, оказывается, уже о девелоперской базе. Я не могу уследить за потоком твоего сознания, определись с мыслями.

Во-вторых, не всегда разработка ведется со своей "чистой" базой. Ты не подумал о том, что есть корпоративные платформенные решения со своими БД (MS Dynamics CRM, SharePoint, Axapta, ECM'ы и т.д.)? Тут уже не удалишь базу, батенька.

что ж так? еще раз, повторяю - изначально я имел ввиду девелоперскую базу, а ты поднял вопрос обновления данных, в это случае - неважно какой подход используется - в любом случае надо генерить скрипт обновления данных, в некоторых случаях и там и там можно обойтись тупо добавлением столбца (например он null), и все это действительно, в том числе, и для Dynamics / SharePoint

МСУА я и не отрицал сего факта - code-first отстой. Засекал - добавить десяток сущностей в контекст 10 секунд (время тупо на выбрать нужные объекты)
а время на создание таблиц в БД забыл? тоже все за 10 секунд, т.е. по секунде на таблицу? ну ты герой, считай секунды лучше

МСУА теперь ты засеки, сколько раз у тебя будет заново пересоздаватья гигобайтная база для того, чтобы тупо добавить поле.

в гигабайтную базу поле я добавлю скриптом, точно так же как и ты для EF, только потом ты пойдешь в дизайнер, и будешь ждать 2-3 минуты обновления контекста, а я добавлю две строчки кода, одна - это само поле в класс, вторая - это маппинг этого поля

МСУВо-вторых, у тебя уже есть сегодняшние наработанные тестовые данные, нужные для разработки, которые похерятся. Ручками заново будешь их вколачивать? Убей себя, серьезно.

конечно есть, в скриптах, когда я жму развернуть базу, заодно разворачиваются тестовые данные
на большую тестовую базу (гигабайтную) - структура БД обновляется скриптами, которые сгенерили руками, и, _еще_раз_, это нужно будет сделать как при использовании EF так и NH

-----

Алексей КДля сохранения можно самостоятельно, без EF, генерить SQL-батчи. Использовать для этого EF никто не заставляет. Не нужно вставлять "всё" в один батч, чтобы MSSQL не ругался на его размеры.

я понимаю что можно, тогда я тупо выкину ORM, зачем она нужна, и да там в некоторых местах была сделана пакетная обработка по 5000-10000 записей, но это тупо костыль

Алексей Кзы: Странная архитектура. Может она причина всех бед?

накладывать ООП на реляционные БД - вообще штука странная

МСУС какого перепугу ORM должна работать с левыми классами? Заставишь поработать ORM, скажем, с классом Thread?

иди еще раз почитай обсуждение, особенно насчет DTO, который и является левым классом для ORM

МСУОчень весомые доказательства. Это всё?

да

МСУ17-77я и не говорил что EF виноват, ошибку с длиной запроса выдавал MS SQL, читай внимательней
А зачем тогда пишешь про это?

17-77xDDD а SOA/WCF - это что по твоему? не слой приложений/служб который 3-tier? мда...
Ты это к чему ляпнул?

читай до тех пор, пока не поймешь, что к чему, не люблю глупости объяснять по 100 раз

МСУИ? Не вижу выводов. Ты констатируешь факты, а выводов нет. Ну трехзвенка, ORM... Что дальше?

аналогично

МСУТолько что открыл дизайнер, обновил контекст, обновилось за 3 секунды. Что я делаю не так?

я откуда знаю, не там считаешь, считай полностью:
1. открытие дизайнера
2. открытие окна подключения к базе
3. время пока это окно обратиться к БД, считает структуру и отобразит тебе дерево объектов
4. поиск нужного объекта
5. выделение галкой
6. нажатие кнопки ОК и ожидание результата

МСУГлупости. Никаких скриптов обновления данных генерить не нужно. А по поводу добавления столбца - верно. Так вот я добавил его, подсунул обновленный контекст и всё заработало. В чем проблема?

епрст, данные не надо обновлять при обновлении структуры базы xD, а мужики-то и не знают
1. добавление колонки not-null, ты там дальше вспоминаешь про дефолтное значение столбца, так вот запомни раз и навсегда - в данном случае это костыль для ленивых программистов, которым насрать на проект или начльник требует сделать побыстрому, дефолтное значение используется для других случаев, например это аналог переноса бизнес-логики в базу данных, в частности - например когда в таблицу пишет некая внешняя система и требуется устанавливать поля в дефолтные значения при отсутствии значений
2. обновление данных может затрагивать более сложные случаи - например
* смена many-to-one, на many-to-many
* добавление not-null столбца, значение которого зависит от некоторых других данных и дефолтного значения там быть не может, например направление (входщий/исходящий), направление "не определено" ака дефолтное значение - это тупо опять костыль, который потом исправлять скриптом обновления данных или иным быстрым способом, потому что пользователям будет лень тыкать кнопки для 10к записей

МСУТолько идиоты под каждый чих пересоздают таблицы в БД. Так что ты чё-то не в кассу сказал.

мда, жесть, еще раз

МСУА я и не отрицал сего факта - code-first отстой. Засекал - добавить десяток сущностей в контекст 10 секунд (время тупо на выбрать нужные объекты)

говорил такое? говорил, так вот при подходе database-first - у тебя нет таблиц в базе (а в начале проекта даже базы нет), ты сначала идешь в СУБД, создаешь через какую-нибудь managment studio базу, потом таблицы, поля там набиваешь, потом идешь в visual studio, в дизайнер EF, и только потом пытаешься их добавить в модель данных EF

и ты мне тут заливаешь про 10 секунд еще, ага на создание базы и десяти таблиц в базе руками, герой

МСУРазвернуть БД из контекста нах не нужно в обсуждаемой теме.

она у тебя из дзена появится?

МСУНакладывают ООП на бизнес-логику, а не на реляционные данные.
опа, а чего ты мне тут тогда втираешь про ORM и EF в частности?