Здравствуйте, 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>Никто не жульничает, все, кроме тебя, прекрасно понимают о чем речь.
Аргументы кончились, переходим на личности, понятно.
Разговоры по делу, делового человека, ничего не скажешь.