Осталось дело за малым, аргументировать использование BLToolkit группе архитекторов и коллегам.
Лично для меня максимально интересна поддержка LINQ & DML.
Но у булкита за время его жизни отросло как я понимаю огромное количество фичей.
Вопрос, те кто использует BLToolkit, опишите наиболее важные лично для вас фичи.
Tom>Вопрос, те кто использует BLToolkit, опишите наиболее важные лично для вас фичи.
Пользовал. Правда линка тогда небыло ещё.
Доступность сорцов. Простота
Здравствуйте, Tom, Вы писали:
Tom>Хочется прибыть в ваш полк
Так и не нашёл ничего человеческого?
Tom>Осталось дело за малым, аргументировать использование BLToolkit группе архитекторов и коллегам.
Я бы начал с объяснения разницы по сравнению с другими ORM инструментами. Можно начать отсюда.
В качестве дополнительных аргументов:
— самый быстрый на сегодняшний день ORM в .NET мире;
— самый богатый список поддерживаемых БД;
— возможность непосредственно влиять на состав фич библиотеки.
Tom>2IT, Тут http://bltoolkit.net/Doc.LinqExtensions.ashx DML так скромно описан, это надо рекламировать как Killer Feature!
Это как раз является следствием принятого подхода. Мы не скрываем БД от программиста, мы предлагаем инстумент облегчающий работу с ней.
Если нам не помогут, то мы тоже никого не пощадим.
Tom>>Хочется прибыть в ваш полк IT>Так и не нашёл ничего человеческого?
IT>Я бы начал с объяснения разницы по сравнению с другими ORM инструментами. Можно начать отсюда.
Уже
IT>В качестве дополнительных аргументов: IT>- самый быстрый на сегодняшний день ORM в .NET мире;
В принципе это важно, хотя конечно в среднестатистических проектах тормоза в основном в БД.
В любом случае скорость это конечно плюс.
IT>- самый богатый список поддерживаемых БД;
Для среднестатистического проекта использутся одна БД, у нас сиквел только.
IT>- возможность непосредственно влиять на состав фич библиотеки.
Хороший пункт.
Tom>>2IT, Тут http://bltoolkit.net/Doc.LinqExtensions.ashx DML так скромно описан, это надо рекламировать как Killer Feature! IT>Это как раз является следствием принятого подхода. Мы не скрываем БД от программиста, мы предлагаем инстумент облегчающий работу с ней.
Это для меня понятно, надеюсь конечно что остальные тоже поймут...
Здравствуйте, Tom, Вы писали:
IT>>- самый богатый список поддерживаемых БД; Tom>Для среднестатистического проекта использутся одна БД, у нас сиквел только.
В принципе да, но определённые 'но', всё же существуют. Для внутренных проектов скорее всего одна БД и другой не надо. Тем не менее, если раньше мы у себя даже не думали о том, чтобы соскочить с Sybase прежде всего по причинам переноса кода на другую СУБД, то сегодня мы такую возможность рассматриваем вполне серьёзно и портирование кода для нас главное проблемой совсем не является. Для внешних проектов практически бесплатная алтернатива в плане БД может оказаться не таким уж и маленьким плюсом. Взять тот же Янус, в нём AVK выбросил всю БД специфику, кроме DDL и один code base используется для 4-х или 5-ти БД.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Вопрос, те кто использует BLToolkit, опишите наиболее важные лично для вас фичи.
LINQ, поддержка апдейтов, возможность использования модели, описанной только интерфейсами, возможность создания кастомных LINQ-подзапросов в виде функций.
Главный недостаток — конфигурация в статиках и монстроидальность DBManager.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>возможность создания кастомных LINQ-подзапросов в виде функций.
А можно по подробнее что это такое?
AVK>Главный недостаток — конфигурация в статиках и монстроидальность DBManager.
Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов.
Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца
Здравствуйте, Tom, Вы писали:
AVK>>возможность создания кастомных LINQ-подзапросов в виде функций. Tom>А можно по подробнее что это такое?
http://www.rsdn.ru/projects/rfd/linq/LinqWithBLToolkit.xml#EISAG
AVK>>Главный недостаток — конфигурация в статиках и монстроидальность DBManager. Tom>Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов. Tom>Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца
Настройки и так в отдельном классе, часть из них конфигурируется через config-файл. Но видимо этого недостаточно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Настройки и так в отдельном классе, часть из них конфигурируется через config-файл. Но видимо этого недостаточно.
Должна быть возможность одновременного существования в рамках одного домена нескольких конфигураций. Сейчас для этого приходится писать не очень красивый и потенциально ненадежный код. А уж через файл оно, или там подпиской на статические события, не столь важно.
Вот погляди на WCF — я могу конечно понаписать мегаконфиг и законфигурить все в нем, могу даже констрейнты программно на этот конфиг наложить. Но при этом я могу взять и собрать конфигурацию программно (см. классы ХххBindingElement для примера), и подсунуть ее конкретному экземпляру ServiceHost, наплевав на все эти конфиги. Вот последнее в BLT до сих пор не очень получается. По идее нужно всю конфигурацию передавать экземпляру DBManager, а из статиков ее брать не напрямую, а специальным отдельным хелпером, т.е. ввести промежуточную абстракцию. Это снизит связность и решит большинство проблем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Tom, Вы писали:
AVK>>Главный недостаток — конфигурация в статиках и монстроидальность DBManager. Tom>Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов.
Да дело не только и не столько в интерфейсах. Там целый ряд рефакторингов нужен. Во-первых выдрать из него кучу хелперов во внешний класс (но сейчас это не очень получается из-за странноватой реализации некоторых методов, которые мне не очень понятно как распутывать). Во-вторых тщательнее отнестись к SRP — DBManager сейчас слишком большой responsibility обладает. Например, инкапсулирует в себе и фабрику коннекшенов, и собственно коннекшен, что сильно пудрит смысл в коде. IT все хочет ввести некий DataContext, но я пока не до конца его мысль понимаю.
И таки да, нужно вводить по крайней мере один интерфейс, чтобы хотя бы формально можно было отодрать всю реализацию BLT из публичных контрактов использующей его сборки.
Tom>Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца
Но чем позже эту песню запеть, тем больше и геморойнее ее петь придется. Ну да я просто назвал лично для меня самые основные pain points в дизайне BLT. На истину в последней инстанции не претендую.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Tom, Вы писали:
AVK>>>Главный недостаток — конфигурация в статиках и монстроидальность DBManager. Tom>>Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов.
AVK>Да дело не только и не столько в интерфейсах. Там целый ряд рефакторингов нужен. Во-первых выдрать из него кучу хелперов во внешний класс (но сейчас это не очень получается из-за странноватой реализации некоторых методов, которые мне не очень понятно как распутывать). Во-вторых тщательнее отнестись к SRP — DBManager сейчас слишком большой responsibility обладает. Например, инкапсулирует в себе и фабрику коннекшенов, и собственно коннекшен, что сильно пудрит смысл в коде. IT все хочет ввести некий DataContext, но я пока не до конца его мысль понимаю.
Согласен, фабрика конекций и сама конекция вообще в один класс не лезет.
А BLT вообзе извне транзакцию можно передать? А то у нас своя реализация TransactionScope-а, в которой отсуствует фатальный недостаток
AVK>И таки да, нужно вводить по крайней мере один интерфейс, чтобы хотя бы формально можно было отодрать всю реализацию BLT из публичных контрактов использующей его сборки.
А DBManager не реализует интерфейса вообще??? Это же как мы его будем тогда в DI испольщовать? на самом деле если это так — то это show stoper (.
Tom>>Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца AVK>Но чем позже эту песню запеть, тем больше и геморойнее ее петь придется. Ну да я просто назвал лично для меня самые основные pain points в дизайне BLT. На истину в последней инстанции не претендую.
Согласен полность, чем позже начинаешь прислушиваться к таким вещим как SRP и DI тем дольше и мучительнее приходится рефакторить. При этом рефакторить всё равно придётся.
Здравствуйте, Tom, Вы писали:
Tom>А BLT вообзе извне транзакцию можно передать?
BLT вообще очень мало что с транзакциями что то делает, есть лишь очень тонкая обертка над ними.
Tom>А DBManager не реализует интерфейса вообще???
Не реализует. Причем без использования конкретного класса DBManager в публичных контрактах не обойтись в принципе.
Tom> Это же как мы его будем тогда в DI испольщовать?
Опосредованно. Сервис свой, а уж у него есть метод получения DBManager.
Tom> на самом деле если это так — то это show stoper (.
Не думаю. Просто не очень красиво, но не более того. Шансов на появление альтернативных реализаций, хорошо совместимых с BLT, практически нет. Специфика LINQ — слишком много неоднозначностей возникает.
Tom>Согласен полность, чем позже начинаешь прислушиваться к таким вещим как SRP и DI тем дольше и мучительнее приходится рефакторить. При этом рефакторить всё равно придётся.
Да дело не только в DI. Вон в янусе как такового полномасштабного DI фреймворка нет. Тем не менее модель у него предполагает в определенной степени гибкость и расширяемость. И этого достаточно, чтобы в свое время пришлось втискивать в нее BLT долго и больно. Особенно задолбала война со статиками. Некоторые углы, в итоге, у BLT пришлось подтесать, но текущая ситуация от совершенства еще очень далека.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>Опосредованно. Сервис свой, а уж у него есть метод получения DBManager.
А толку. Если интерфейса нет — значит и stub не написать
Tom>> на самом деле если это так — то это show stoper (. AVK>Не думаю. Просто не очень красиво, но не более того. Шансов на появление альтернативных реализаций, хорошо совместимых с BLT, практически нет. Специфика LINQ — слишком много неоднозначностей возникает.
Я имел ввиду что мы стараемся идти к SOLID соответственно повсеместно использовать DI, а базовый тул который не реализует ни одного интерфейса — это проблема.
AVK>Да дело не только в DI. Вон в янусе как такового полномасштабного DI фреймворка нет. Тем не менее модель у него предполагает в определенной степени гибкость и расширяемость. И этого достаточно, чтобы в свое время пришлось втискивать в нее BLT долго и больно. Особенно задолбала война со статиками. Некоторые углы, в итоге, у BLT пришлось подтесать, но текущая ситуация от совершенства еще очень далека.
Здравствуйте, pr0ff, Вы писали:
P>Здравствуйте, Tom, Вы писали:
Tom>>2IT, Тут http://bltoolkit.net/Doc.LinqExtensions.ashx DML так скромно описан, это надо рекламировать как Killer Feature!
P>Никакого Killer Feature, это и вM$ LINQ to SQL возможно
Пример в студию
Здравствуйте, Tom, Вы писали:
AVK>>Опосредованно. Сервис свой, а уж у него есть метод получения DBManager. Tom>А толку. Если интерфейса нет — значит и stub не написать
А зачем тебе stub для DBManager? Для тестов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>А зачем тебе stub для DBManager? Для тестов?
Да не только для тестов.
Допустим DBManager является фабрикой конекций, и мне нужно использовать данную фичу.
Я с бОльшей радостью передам в класс/метод маленький интерфейс аля IConnectionFactory который реализует пару методов вместо огромного класса DBManager.
Здравствуйте, Tom, Вы писали:
Tom>Хочется прибыть в ваш полк
простота, расширяемость, возможность делать то, что надо мне и так, как я считаю это нужным, возможность свалить часть своей работы на IT, поклянчив фичу
зимой планирую таки перетащить проект под LINQ, надо сделать поддержку разных БД (не то что бы я хотел, а жизнь заставляет )
из минусов — оно конечно все просто, но учиться приходится не по учебникам а в "бою" (я в свое время чуть не посидел, пока юнит-тесты как доки читать научился... хотя это тоже был полезный опыт).
Здравствуйте, IT, Вы писали:
IT>... Мы не скрываем БД от программиста, мы предлагаем инстумент облегчающий работу с ней.
Либо другие ORM тоже не скрывают БД от программиста, либо вы скрываете БД за удобным инструментом.
Здравствуйте, Alexander Polyakov, Вы писали:
IT>>... Мы не скрываем БД от программиста, мы предлагаем инстумент облегчающий работу с ней. AP>Либо другие ORM тоже не скрывают БД от программиста, либо вы скрываете БД за удобным инструментом.
Это неверное утверждение. Тяжёлые ORM как раз пытаются всучить программисту объектную модель и предлагают работать по возможности только с ней. При этом объектная модель может и не совпадать полностью с моделью данных приложения. Чего стоит только сама идея проектирования объектной модели, а уже по ней генерации модели данных? Например, ребятам из DataObjects вообще пришлось сделать отдельную базу для тестов на OrmBattle, т.к. стандартной Northwind им ну никак не хватает. Им нужны в БД какие-то свои дополнительные сущности. Все эти entity services, прибитые гвоздями к ORM — кеши, лейзи лоадинги, ченчь трэкинги, обжект айдентити, это разве не попытка скрыть от программиста суть вещей. Persistent storage — вот главная идея тяжелых ORM. Другой нет.
Другое дело, что программисты не всегда с этим согласны и нет-нет, а пытаются разглядеть базу данных за дырявой занавеской, которой является persistent storage.
BLToolkit всякой такой фигнёй не страдает по определению. Мы предлагаем helper, ни больше, ни меньше. Просто helper для работы с БД и ничего ни от кого не скрываем. Как раз наоборот нас часто ругают именно за это и просят побольше поскрывать.
AP>Linq скрывает язык базы SQL.
Linq если что-то и скрывает, то только специфику конкретного диалекта SQL.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>... Тяжёлые ORM как раз пытаются всучить программисту объектную модель и предлагают работать по возможности только с ней. При этом объектная модель может и не совпадать полностью с моделью данных приложения. Чего стоит только сама идея проектирования объектной модели, а уже по ней генерации модели данных? Например, ребятам из DataObjects вообще пришлось сделать отдельную базу для тестов на OrmBattle, т.к. стандартной Northwind им ну никак не хватает. Им нужны в БД какие-то свои дополнительные сущности. Все эти entity services, прибитые гвоздями к ORM — кеши, лейзи лоадинги, ченчь трэкинги, обжект айдентити, это разве не попытка скрыть от программиста суть вещей. Persistent storage — вот главная идея тяжелых ORM. Другой нет.
Где тут скрытие базы? Это всё “удобства” инструмента.
AP>>Linq скрывает язык базы SQL. IT>Linq если что-то и скрывает, то только специфику конкретного диалекта SQL.
Есть язык L1, есть язык L2. База данных работает с языком L1. Некоторый инструмент/методология говорит нам использовать L2. Где у нас язык L1? Правильно, его у нас нет. Другими словами, язык L1 от нас скрыли.
И не важно насколько похожи или не похожи языки L1 и L2.
Другое дело, что нам все же разрешают пользоваться языком L1. Но если слово “скрывать/не скрывать” понимать в этом смысле, то тогда другие ORM не скрывают базу. Там тоже разрешают лазить в базу.
Таким образом, повторю: “либо другие ORM тоже не скрывают БД от программиста, либо вы скрываете БД за удобным инструментом”.
Здравствуйте, Alexander Polyakov, Вы писали:
IT>>... Тяжёлые ORM как раз пытаются всучить программисту объектную модель и предлагают работать по возможности только с ней. При этом объектная модель может и не совпадать полностью с моделью данных приложения. Чего стоит только сама идея проектирования объектной модели, а уже по ней генерации модели данных? Например, ребятам из DataObjects вообще пришлось сделать отдельную базу для тестов на OrmBattle, т.к. стандартной Northwind им ну никак не хватает. Им нужны в БД какие-то свои дополнительные сущности. Все эти entity services, прибитые гвоздями к ORM — кеши, лейзи лоадинги, ченчь трэкинги, обжект айдентити, это разве не попытка скрыть от программиста суть вещей. Persistent storage — вот главная идея тяжелых ORM. Другой нет. AP>Где тут скрытие базы? Это всё “удобства” инструмента.
Удобства — это когда инструмент не диктует свою идеологию, а его фичи можно применять по своему усмотрению в любых комбинациях и в любом месте.
AP>>>Linq скрывает язык базы SQL. IT>>Linq если что-то и скрывает, то только специфику конкретного диалекта SQL. AP>Есть язык L1, есть язык L2. База данных работает с языком L1. Некоторый инструмент/методология говорит нам использовать L2. Где у нас язык L1? Правильно, его у нас нет. Другими словами, язык L1 от нас скрыли.
Что скрыли? SELECT или WHERE? Так они есть и там и сям. Linq даёт возможность писать запросы в терминах приложения, а не строковых литералов. Только и всего. Есть конечно свои дополнительные плюшки вроде ассоциаций и дополнительных оптимизаций, есть определённые неудобства вроде идиотского LEFT JOIN и вывернутого наизнанку IN, но в целом что пишем на Linq, то и получаем в SQL.
AP>Другое дело, что нам все же разрешают пользоваться языком L1. Но если слово “скрывать/не скрывать” понимать в этом смысле, то тогда другие ORM не скрывают базу. Там тоже разрешают лазить в базу.
Разрешается только потому, что как я уже сказал, разработчики всё равно хотят работать с БД, а не с persistent storage. Приходится разрешать, иначе какашками закидают.
AP>Таким образом, повторю: “либо другие ORM тоже не скрывают БД от программиста, либо вы скрываете БД за удобным инструментом”.
А сам-то как думаешь? Первое или второе?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexander Polyakov, Вы писали:
IT>>Linq если что-то и скрывает, то только специфику конкретного диалекта SQL. AP>Есть язык L1, есть язык L2. База данных работает с языком L1. Некоторый инструмент/методология говорит нам использовать L2. Где у нас язык L1? Правильно, его у нас нет. Другими словами, язык L1 от нас скрыли.
Язык — фигня. Преобразования от одного к другому могут быть довольно сложными алгоритмически, но обычно вполне решаемы и не создают непреодолимых барьеров.
Намного хуже, когда не совпадают модели данных. И вот как раз LINQ вообще и BLT в частности позволяют работать в рамках реляционной модели, и в этом их прелесть. А вот тяжелые ORM работают в рамках модели объектной, и, как следствие, собирают полный набор граблей при переходе к реляционному хранилищу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Язык — фигня. Преобразования от одного к другому могут быть довольно сложными алгоритмически, но обычно вполне решаемы и не создают непреодолимых барьеров. AVK>Намного хуже, когда не совпадают модели данных. И вот как раз LINQ вообще и BLT в частности позволяют работать в рамках реляционной модели, и в этом их прелесть. А вот тяжелые ORM работают в рамках модели объектной, и, как следствие, собирают полный набор граблей при переходе к реляционному хранилищу.
Разработчики тяжелых ORM поют похожие песни, только у них не “язык -- фигня”, a “реляционная модель -- фигня”.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Разработчики тяжелых ORM поют похожие песни, только у них не “язык -- фигня”, a “реляционная модель -- фигня”.
Ну вот, а сам говоришь не скрывают. Пытаются, да только фигово это получается.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Разработчики тяжелых ORM поют похожие песни, только у них не “язык -- фигня”, a “реляционная модель -- фигня”.
Неважно, кто и что поет. Главное — результат.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Неважно, кто и что поет. Главное — результат.
Результат говорите, а что такое результат? В глобальном плане явно рулит Java, в которой нет Linq и как раз преобладают толстые ORM. В локальном, какой проект вы готовы обсудить в деталях? ваш или мой?
IT>...ченчь трэкинги...
Однако Change Tracking бывает полезен. Я говорю сейчас о tracking-е изменённых в entity полей для того что бы в сгенерённом UPDATE-е учавствовали только эти, изменённые поня. Это позволяет избежать подхода:
1. Прочитали из БД всю запись
2. Изменили пару полей
3. Влили всю запись
На:
1. Создали запись
2. Поменяли пару полей
3. Влили запись
Тут мы избегаем одного раундтрипа на сервер.
Change Tracking же на уровне рядов, (удалённых/изменённых/вставленных) ака UnitOfWork нафиг не нужен.
Здравствуйте, Tom, Вы писали:
Tom>Однако Change Tracking бывает полезен. Я говорю сейчас о tracking-е изменённых в entity полей для того что бы в сгенерённом UPDATE-е учавствовали только эти, изменённые поня.
Полезным может оказаться всё из вышеперечисленного. Проблема в том, что чаще всего это всё прибито гвоздями к инструменту и практически неотчуждаемо. А можно это всё сделать отдельно и подключать по необходимости.
Tom>1. Прочитали из БД всю запись Tom>2. Изменили пару полей Tom>3. Влили всю запись
Tom>На: Tom>1. Создали запись Tom>2. Поменяли пару полей Tom>3. Влили запись
Tom>Тут мы избегаем одного раундтрипа на сервер.
Это как?
Tom>Change Tracking же на уровне рядов, (удалённых/изменённых/вставленных) ака UnitOfWork нафиг не нужен.
Ну не знаю. Юайщикам бывает нужно.
Если нам не помогут, то мы тоже никого не пощадим.
IT>Это как?
Вместо 2-х запросов SELECT & UPDATE у нас остаётся только UPDATE в котором перечислено лишь то что реально поменялось
IT>Ну не знаю. Юайщикам бывает нужно.
Имеется ввиду видимо решение с удалённвым клиентом который редактирует нечто и потом отсылает все изменения на сервер?
Здравствуйте, Tom, Вы писали:
IT>>Это как? Tom>Вместо 2-х запросов SELECT & UPDATE у нас остаётся только UPDATE в котором перечислено лишь то что реально поменялось
Как можно изменить объект, предварительно его не прочитав?
IT>>Ну не знаю. Юайщикам бывает нужно. Tom>Имеется ввиду видимо решение с удалённвым клиентом который редактирует нечто и потом отсылает все изменения на сервер?
Не важно что куда отсылается. Важно, что работа идёт со списком, например, в гриде, а потом все изменения сохраняются.
Если нам не помогут, то мы тоже никого не пощадим.
IT>Как можно изменить объект, предварительно его не прочитав?
Прекрасно, зачем что то читать только для того что бы изменить?
В запросе UPDATE AAA SET BBB=CCC не присуствует старых данных, только новые.
Соответственно зачем лишний раз ходить в БД что бы прочитать обьект.
Можно сделать new MyEntity(){BBB=CCC} и потом выполнить UPDATE передав MyEntity
IT>Не важно что куда отсылается. Важно, что работа идёт со списком, например, в гриде, а потом все изменения сохраняются.
Возможно
Здравствуйте, Tom, Вы писали:
IT>>Как можно изменить объект, предварительно его не прочитав? Tom>Прекрасно, зачем что то читать только для того что бы изменить? Tom>В запросе UPDATE AAA SET BBB=CCC не присуствует старых данных, только новые. Tom>Соответственно зачем лишний раз ходить в БД что бы прочитать обьект. Tom>Можно сделать new MyEntity(){BBB=CCC} и потом выполнить UPDATE передав MyEntity
Ты ещё про условие забыл, а то так можно все поля в таблице одним разом махнуть не глядя.
Это уже и сейчас можно сделать, используя DML операции и не для одного объекта, а для скольки получится.
db.Employee
.Where(e => e.Title == "Spectre")
.Update(e => new Northwind.Employee
{
Title = "Commander"
});
Если нам не помогут, то мы тоже никого не пощадим.
IT>Это уже и сейчас можно сделать, используя DML операции и не для одного объекта, а для скольки получится.
Да это то понятно но change tracking-а изменённых полей то тут нету. Надо самому как то разбираться что изменилось.
Это конечно не принципиалная проблема, всё решаемо конечно.
Здравствуйте, Alexander Polyakov, Вы писали:
AVK>>Неважно, кто и что поет. Главное — результат. AP>Результат говорите, а что такое результат? В глобальном плане явно рулит Java
Тебе пофлеймить захотелось? Тогда в другой форум. По делу есть что сказать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Ну а по делу, например, вот, в статье про pureQuery тоже обсуждается термин “скрытие\не скрытие базы”. Под “скрытием базы” там имеется в виду что скрывается SQL. Т.е. это совпадает с моей точкой зрения. А Вы не честно играете, жульничаете, используете термин “мы не скрываем базу”, который на самом деле означает “мы не срываем модель данных базы”.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>А Вы не честно играете, жульничаете, используете термин “мы не скрываем базу”, который на самом деле означает “мы не срываем модель данных базы”.
Никто не жульничает, все, кроме тебя, прекрасно понимают о чем речь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Никто не жульничает, все, кроме тебя, прекрасно понимают о чем речь.
Аргументы кончились, переходим на личности, понятно.
Разговоры по делу, делового человека, ничего не скажешь.
Здравствуйте, Alexander Polyakov, Вы писали:
AVK>>Никто не жульничает, все, кроме тебя, прекрасно понимают о чем речь. AP>Аргументы кончились, переходим на личности, понятно.
Тебе показалось.
AP>Разговоры по делу, делового человека, ничего не скажешь.
А вот это уже натуральный переход на личности. Впрочем, я иного и не ожидал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Тебе показалось. AVK>... AVK>А вот это уже натуральный переход на личности....
Продолжаете демонстрировать двойные стандарты.
Здравствуйте, Tom, Вы писали:
Tom>Таких поделок достаточно много, мне нужен продукт а не пример. Причём продукт который хотя бы кто то готов поддерживать.
Здравствуйте, pr0ff, Вы писали:
P>Здравствуйте, Tom, Вы писали:
Tom>>Таких поделок достаточно много, мне нужен продукт а не пример. Причём продукт который хотя бы кто то готов поддерживать.
P>Да вот только с этими поделками никогда не было проблем, в отличии от BLT. P>[bug] LINQ Update and Take
Здравствуйте, SkySandy, Вы писали: SS>Для темы: баг в LINQ Update, поражает Ваша фраза "У меня сейчас полно дел, а SQL Profiler почему-то вылетает"
Я рад, что она Вас поразила
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, pr0ff, Вы писали:
P>>Да вот только с этими поделками никогда не было проблем, в отличии от BLT. P>>[bug] LINQ Update and Take
F>> EF без слёз использовать вообще не возможно. P>так это не EF, а LINQtoSQL
Это к слову о поделках с которыми никогда не бывает проблем. И баги в том числе есть везде и всякие.
Если нам не помогут, то мы тоже никого не пощадим.
