Здравствуйте, AndrewVK, Вы писали:
AVK>Зная примерно, что ис себя представляет тим, который EF занимается, я бы тебе не советовал особо на это рассчитывать. AVK>Кстати, какое то время это чудо пытались как раз mssql team спихнуть, но те от него отпихались руками и ногами.
Вполне представляю. Чтоб написать нормальный ORM нужно набить достаточно много шишек. Сам .NET тоже в первом релизе был печальным зрелищем.
Sapienti sat!
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, AndrewVK, Вы писали:
C>>Вполне представляю. Чтоб написать нормальный ORM нужно набить достаточно много шишек. AVK>Шишки там начинались еще с ObjectSpaces, если не раньше. Не обольщайся, это не временные шишки, это уже устоявшиеся воззрения.
ObjectSpaces — это был очень примитивный фреймворк. Интересно, а его команда в развитии EF участвовала?
Вообще, хороший ORM-фреймворк — это весьма сложная штука. Слишком многое можно сделать неправильно.
Sapienti sat!
Re[27]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
C>ObjectSpaces — это был очень примитивный фреймворк.
Это очень хороший фреймворк. Патамуша мертвый
C> Интересно, а его команда в развитии EF участвовала?
Да. Выдающаяся по количеству убитых проектов команда (WinFS тоже на их груди сияет, если что). Я вот уже думал, что наконец то один успешный проект появился — linq2sql. Ан нет, они и его похоронили. И EF они тоже похоронят, не сомневайся Неудачники
C>Вообще, хороший ORM-фреймворк — это весьма сложная штука.
В этом и проблема.
C> Слишком многое можно сделать неправильно.
А самое главное, даже когда сделаешь — все одно непонятно, правильно оно или нет. Тестирую то все больше на игрушечных сценариях, когда много редактирования и мало массовых операций, и никаких тебе интерпрайз заморочек.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>ObjectSpaces — это был очень примитивный фреймворк. AVK>Это очень хороший фреймворк. Патамуша мертвый
C>> Интересно, а его команда в развитии EF участвовала? AVK>Да. Выдающаяся по количеству убитых проектов команда (WinFS тоже на их груди сияет, если что).
Охх... Да. Теперь я понял всю глубину ситуации.
AVK>Я вот уже думал, что наконец то один успешный проект появился — linq2sql. Ан нет, они и его похоронили. И EF они тоже похоронят, не сомневайся Неудачники
Осталось перевести эту группу в отдел ядра Windows, и Линукс можно считать победившим.
C>> Слишком многое можно сделать неправильно. AVK>А самое главное, даже когда сделаешь — все одно непонятно, правильно оно или нет. Тестирую то все больше на игрушечных сценариях, когда много редактирования и мало массовых операций, и никаких тебе интерпрайз заморочек.
Да, это тоже. В первых крупных проектах, использующих Hibernate, в самом Hibernate пришлось много багов править.
Впрочем, Microsoft любит на покупателях эксперименты ставить.
Sapienti sat!
Re[29]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
C>Осталось перевести эту группу в отдел ядра Windows, и Линукс можно считать победившим.
Там своих индусов хватает. Но там башка имеется из суровых мужиков, в отличие от.
C>Впрочем, Microsoft любит на покупателях эксперименты ставить.
Ну, это ты зря. МС как раз таки очень не любит рискованных стратегий, за что ее регулярно полоскают в том числе и на этом форуме. Мол, вот, опять, ну ничего революционного, все стырили.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>Осталось перевести эту группу в отдел ядра Windows, и Линукс можно считать победившим. AVK>Там своих индусов хватает. Но там башка имеется из суровых мужиков, в отличие от.
Пусть возьмут на работу создателя Hibernate — он может им расскажет как не надо делать
C>>Впрочем, Microsoft любит на покупателях эксперименты ставить. AVK>Ну, это ты зря. МС как раз таки очень не любит рискованных стратегий, за что ее регулярно полоскают в том числе и на этом форуме. Мол, вот, опять, ну ничего революционного, все стырили.
Ну некоторые продукты МС никак кроме как бэта-версиями назвать нельзя. Тут Vista лидирует, которая до SP1 имела кучу критичных проблем.
Sapienti sat!
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
C>Ну некоторые продукты МС никак кроме как бэта-версиями назвать нельзя. Тут Vista лидирует, которая до SP1 имела кучу критичных проблем.
Ну, лично я ничего критичного не заметил. Опять же, смотря с чем сравнивать. По сравнению с очередным продуктом адоба или автодеска виста просто идеал безглючности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>Ну некоторые продукты МС никак кроме как бэта-версиями назвать нельзя. Тут Vista лидирует, которая до SP1 имела кучу критичных проблем. AVK>Ну, лично я ничего критичного не заметил. Опять же, смотря с чем сравнивать.
Баги с копированием файлов не иначе как бэта-тестом на пользователях назвать нельзя было, например.
AVK>По сравнению с очередным продуктом адоба или автодеска виста просто идеал безглючности.
Ну да, это они пример у MS взяли.
Sapienti sat!
Re[15]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
IT>>Вот не надо. MS уже не однократно доказывала, что может как понять, так потом и перепонять. В своё время датасеты проталкивались как единственно возможное решение в области работы с БД. Что-то я последнее время про них совсем не слышу. Сольют L2S и EF и если получится такая же лажа как Hibernate, то перепоймут и сделают как надо. C>Ну вот как перепоймут — так я и окажусь неправ
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[16]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, yuriylsh, Вы писали:
C>>Ну вот как перепоймут — так я и окажусь неправ Y>Боюсь, касаемо L2S — уже Здесь и далее по ссылкам
Собственно, я именно об этом и говорю.
Sapienti sat!
Re[23]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
C>>>Я сравнивал на практике [N]Hibernate с BLToolkit, iBatis и датасетами. Hibernate уверенно лидирует. IT>>Лидирует в чём? C>В скорости разработки и цене поддержки.
О как? Интересно, какими ты методиками пользовался при оценке скорости разработки и цены поддержки?
IT>>Ликов не может быть в принципе. Но можно зацепить объекты за статические переменные или за события и тогда они не будут освобождены никогда. C>Это обычно и называют "memory leak"'ами в managed-приложения.
Так это называют только невежды.
C>>>Ну вот вижу, что проект сильно ускорился после введения Hibernate вместо iBatis. Реальный эффект, однако. Делаю вывод: Hibernate увеличивает производительность труда. IT>>Я не сомневаюсь в правильности твоего вывода. Но это не делает эту технологию менее проблемной. C>Если технология проблемная, но работает, то она не проблемная
Проблемная технология всегда остаётся проблемной. Умение ходить по граблям не уменьшает количество граблей. C++ девелоперы всю жизнь ходят по граблям и это не делает C++ более качественной технологией. Точно так же и с Хайбернейт.
IT>>Что будет с EF посмотрим. Мой прогноз — мыши плакали, кололись, но продолжали жрать кактус C>Мой прогноз: мы увидим дальнейшее движение в сторону от баз данных и голого SQL к более высокоуровневым средствам. EF будут совершенствовать, возможно интегрировав в SQL Server частичную поддержку для средств ООП.
Вот тоже хороший пример. Когда в SQL 2005 добавляли поддержку .NET, то крику было немеряно. В результате оказалось чисто маркетинговый ход, в Oracle Java, в MS SQL .NET. Добавили и успокоились, а на практике практически никто не использует.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, IT, Вы писали:
C>>В скорости разработки и цене поддержки. IT>О как? Интересно, какими ты методиками пользовался при оценке скорости разработки и цены поддержки?
По времени разработки новых фич и проценту времени на багфиксинг.
C>>Это обычно и называют "memory leak"'ами в managed-приложения. IT>Так это называют только невежды.
Нет. Это устоявшаяся терминилогия: http://www.ej-technologies.com/products/jprofiler/overview.html http://radio.weblogs.com/0118231/stories/2005/07/21/tipsForUsingHeapWindowAndMemoryProfilerToFindMemoryLeaks.html
...
IT>Вот тоже хороший пример. Когда в SQL 2005 добавляли поддержку .NET, то крику было немеряно. В результате оказалось чисто маркетинговый ход, в Oracle Java, в MS SQL .NET. Добавили и успокоились, а на практике практически никто не использует.
Это было вполне предсказуемо. Нужна не возможность запуска хранимых процедур на .NET, а именно интеграция с самой системой хранения и представления данных.
Sapienti sat!
Re[25]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
IT>>О как? Интересно, какими ты методиками пользовался при оценке скорости разработки и цены поддержки? C>По времени разработки новых фич и проценту времени на багфиксинг.
Здравствуйте, IT, Вы писали:
C>>По времени разработки новых фич и проценту времени на багфиксинг. IT>И как долго ты использовал BLToolkit, чтобы научиться его эффективно использовать? А Хайбернейт.
Команда, которая его использовала, имела опыт примерно в год его использования. Hibernate я использовал дольше, но команда выучилась сравнительно быстро.
C>>http://radio.weblogs.com/0118231/stories/2005/07/21/tipsForUsingHeapWindowAndMemoryProfilerToFindMemoryLeaks.html IT>Так это Java, может в ней и есть лики, я не в курсе.
Имеются в виду те же самые лики — если граф объектов зацепляется за какую-то статическую переменную.
Здравствуйте, Cyberax, Вы писали:
IT>>И как долго ты использовал BLToolkit, чтобы научиться его эффективно использовать? А Хайбернейт. C>Команда, которая его использовала, имела опыт примерно в год его использования. Hibernate я использовал дольше, но команда выучилась сравнительно быстро.
Понятно. Сам ты не знаешь. Жаль. Хотелось бы пообщаться с теми, кто всё-таки пробовал вкус апельсина.
C>Имеются в виду те же самые лики — если граф объектов зацепляется за какую-то статическую переменную. C>Вот для .NET:
Я ещё раз повторяю, это безграмотно. Использование этого термина для обозначения совершенно другой проблемы обосновано внешней похожестью проблемы и бедной фантазией людей его использующего.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, IT, Вы писали:
C>>Команда, которая его использовала, имела опыт примерно в год его использования. Hibernate я использовал дольше, но команда выучилась сравнительно быстро. IT>Понятно. Сам ты не знаешь. Жаль. Хотелось бы пообщаться с теми, кто всё-таки пробовал вкус апельсина.
Знаю, почему же. По-моему, по твоей рекомендации его в первый раз и посмотрел.
C>>Вот для .NET: IT>Я ещё раз повторяю, это безграмотно. Использование этого термина для обозначения совершенно другой проблемы обосновано внешней похожестью проблемы и бедной фантазией людей его использующего.
Придумай другой термин Я где-то видел "excessive object retention", но как-то совсем не звучит.
Sapienti sat!
Re[13]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Sergey T., Вы писали:
ST> Если в приложении, грубо говоря, нужно только строить по данным отчеты — то там не нужны ОРМ и т.п.
Именно... Фишка-то ровно в том, что если присмотреться к типичному приложению, которое активно использует БД, то там процентов 90-95 работы — это отчеты. Список товаров в заказе — отчет, история заказов — отчет, адреса доставки — отчет, ect...
ST>Однако, ситуация меняется, когда данные нужно обрабатывать, то есть когда выделяются такие вот сущности типа Customer->Orders->OrderItems->Product->Vendor... ->Region, и эти сущности нужно редактировать, передавать их как параметры,
О! Вот именно в таких сценариях, каждый лишний метод в данных — повод к геморрою.
ST> А если к этому нужно добавить и пользовательский интерфейс соответсвующий, и валидацию ввода, и метаданные, и еще чего-нибудь... К данным это добавить тяжелее. Согласитесь.
Так именно об этом я и толкую. Добавлять этот функционал нужно не к данным, а к внешним сервисам.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[31]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, Cyberax, Вы писали:
C>Пусть возьмут на работу создателя Hibernate — он может им расскажет как не надо делать
Ка не надо делать — знают все, никто не знает как надо...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re[14]: Взаимодействие с Базой Данных из C# по схеме MS
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Gaperton, Вы писали:
G>>Я тебе чисто, как настоящий сварщик своему коллеге, скажу в ответ вот что. Вступление. IB>А я, типа, только каску держал?
G>>Лет 10 назад мы с друзьями занимались корпоративными приложениями на базе RDBMS, и были рьяниыми сторонниками нормализации и многоуровневых архитектур. IB>Нормализация тут непричем. Реляционка хороша тем, что связи там протаптываются с другого конца, чем в OO, в следствии чего любая иерархия строится по месту, а не прибивается гвоздями на этапе проектирования. И такой способ работы с данными удобнее, так как иерархия объектов сильно зависит от конкретного юзкейса и вообще имеет тенденцию эволюционировтаь в процессе эксплуатации приложения и изменениия требований.
Как говорил один мой знакомый — "да, и нет".
У тебя все равно юзкейсы делятся на два класса. 1 — "гуевые" кейсы, которые связанны со вводом информации и OLAP. Эти кейсы отлично кладутся на "расширенную реляционную модель" — где у тебя вместо кортежей тегированные деревья.
И вторая группа кейсов связанна с аналитикой — так не надо аналитику по "документам" строить . Заводишь ROLAP-звезды, и строишь отчеты по ним. Каждый "документ" (объект, соответствующий действию) создает при записи движение в нужных звездах. При этом, у тебя аналитика получается развязана с оперативным учетом — связь происходит посредством описания операций "проведения документов". И все.
Поэтому, на практике при таком подходе получается, что тебе чаще всего просто не нужна способность реляционной модели натягивать иерархию с любой точки. Ты платишь за это избыточностью информации, примерно двукратной. Зато приобретаешь очень интересные полезные свойства. Например, у тебя элементарно все быстрее работает, за счет того, что join-ов стало меньше.