Здравствуйте, Аноним, Вы писали:

VD>>Серьезно? И чем же они помогают?

А>Тебе ничем. Коси траву в противогазе ибо так труднее. )))

Очень похоже на слив. В принципе, можно засчитать.

А>Юзайте, дети мои, то что вашей душе угодно.

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

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

IT>К сожалению, продукты вроде гибернэйта узурпировали термин ORM полностью, хотя давно ушли в другую сторону и этому термину уже не соответствуют. Мне тоже такая ситуация не нравится, но, думаю, вряд ли уже можно что-то сделать. Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM, а там дальше видно будет.

Никуда они не уходили. Они родились такими. Идею персистентности мусировали в Корбе еще до того как Ява стала популярна. О Гибернейте тогда даже речи не шло.

Что до названий, то мне кажется имеет смысл придумать совсем новое название в котором не было бы даже упоминания об объектах и отображении. Ну, как в LINQ-е. Например, можно назвать это дело Object Relation Integrator — ORI.

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

C>"Иди перепиши Nemerle, чтоб всегда работал быстрее кода на С"

А что булкит на С написан и по этому в скорости выигрывает?

C>В смысле: "А нафига"? Люди пишут приложения на Питоне и PHP, которые в 100-200 раз медленнее С.

А, ну, то есть гибернэйт это средство предназначенное для того, чтобы снизить скорость еще на порядок? Крутяк! :))

Если серьезно, то я как бы и не спорю, что для людей не осиливших работу со списками и сидящих на ПХП — гибернэйта за глаза хватит. Только для них гибернэйт — это слишком сложно. Им лучше что-то типа "рельсов".
Но вот на фиг гибернэйт нужен для людей у которых присутствует интеллект я понять не могу.

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

VD>Например, можно назвать это дело Object Relation Integrator — ORI.

Назвать можно, только кто этим названием пользоваться будет?

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

AVK>Я бы не сказал. Возврат из запроса массива сконструированных по месту кортежей для linq2sql не запасной парашут, а совершенно нормальный, основной режим работы, что есть характернейший признак LW/ORM. Для всех H/ORM характерным является возвращение активных коллекций, что в linq2sql наблюдается только в довольно специфичных случаях.

На мой взгляд реляционные свойств нужно было бы сделать такого типа, чтобы из него нельзя было бы без приседаний получить данные напрямую. Тогда в запросах все работало бы ОК, а когда человек пытался бы взять данные чтобы побегать с ними с помощью цикла, то он бы сразу встречал бы проблемы и понимал, что это не тот способ который предлагается как основной.

Скажем доступ к данным можно было бы получать с помощью некого метода LoadData() или GetReader().

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

VD>>Например, можно назвать это дело Object Relation Integrator — ORI.

IT>Назвать можно, только кто этим названием пользоваться будет?

Ты. Глядишь станешь главным родоначальником нового ту-вэя! :))

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

C>>"Иди перепиши Nemerle, чтоб всегда работал быстрее кода на С"
VD>А что булкит на С написан и по этому в скорости выигрывает?
Нет, это примерно такое же по глупости выражение. Немерль ты выбираешь вовсе не из-за того, что он быстрее С.

C>>В смысле: "А нафига"? Люди пишут приложения на Питоне и PHP, которые в 100-200 раз медленнее С.
VD>А, ну, то есть гибернэйт это средство предназначенное для того, чтобы снизить скорость еще на порядок? Крутяк!
Угу.

VD>Если серьезно, то я как бы и не спорю, что для людей не осиливших работу со списками и сидящих на ПХП — гибернэйта за глаза хватит. Только для них гибернэйт — это слишком сложно. Им лучше что-то типа "рельсов".
VD>Но вот на фиг гибернэйт нужен для людей у которых присутствует интеллект я понять не могу.
Ты просто не умеешь им пользоваться. Или делаешь такие приложения, где пофиг чем пользоваться.

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

C>Нет, это примерно такое же по глупости выражение. Немерль ты выбираешь вовсе не из-за того, что он быстрее С.

Я его выбираю потому, что он сравним с С по скорости и сильно превосходит его по выразительности и удобству.
А вот за что выбираю Гибирнэйт? Он ведь по скорости сильно уступает булкиту, и при этом еще и отстает от него по выразительности. :xz:

VD>>Если серьезно, то я как бы и не спорю, что для людей не осиливших работу со списками и сидящих на ПХП — гибернэйта за глаза хватит. Только для них гибернэйт — это слишком сложно. Им лучше что-то типа "рельсов".
VD>>Но вот на фиг гибернэйт нужен для людей у которых присутствует интеллект я понять не могу.
C>Ты просто не умеешь им пользоваться. Или делаешь такие приложения, где пофиг чем пользоваться.

Ну, или ты не умеешь пользоваться альтернативами вроде линка и булкита.

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

C>>Нет, это примерно такое же по глупости выражение. Немерль ты выбираешь вовсе не из-за того, что он быстрее С.
VD>Я его выбираю потому, что он сравним с С по скорости и сильно превосходит его по выразительности и удобству.
VD>А вот за что выбираю Гибирнэйт? Он ведь по скорости сильно уступает булкиту, и при этом еще и отстает от него по выразительности.
По выразительности Булкиту до настоящего ORM — как до Луны. Как появится lazy loading и автодетект изменений, тогда посмотрим.

VD>>>Но вот на фиг гибернэйт нужен для людей у которых присутствует интеллект я понять не могу.
C>>Ты просто не умеешь им пользоваться. Или делаешь такие приложения, где пофиг чем пользоваться.
VD>Ну, или ты не умеешь пользоваться альтернативами вроде линка и булкита.
Умею. Но у меня просто не стандартное веб приложение — у меня изменения графа объектов с сервера реплицируются на клиенты. Причём каждый клиент имеет свой собственный вид графа, с учётом ACL и некоторых настроек.

Нормальный ООП для данных, с поддержкой ссылок, у меня получился просто незаменим.

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

C>По выразительности Булкиту до настоящего ORM — как до Луны. Как появится lazy loading и автодетект изменений, тогда посмотрим.

Надеюсь, при мне это никогда не появится. Тем не менее, если тебе хочется поговорить о выразительности не на словах, а на деле, то мы можем с тобой посостязаться. Давай возьмём какой-нибудь PetShop и сравним код на булките и NH.

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

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

G>>linq2sql — больше H/ORM.

AVK>Я бы не сказал. Возврат из запроса массива сконструированных по месту кортежей для linq2sql не запасной парашут, а совершенно нормальный, основной режим работы, что есть характернейший признак LW/ORM. Для всех H/ORM характерным является возвращение активных коллекций, что в linq2sql наблюдается только в довольно специфичных случаях.
Ну тогда EF вообще lw/orm, только несколько просчетов не позволяют использовать его в этом качестве на полную катушку. (кстати эти просчеты у EFv4 исправлены).

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

C>>По выразительности Булкиту до настоящего ORM — как до Луны. Как появится lazy loading и автодетект изменений, тогда посмотрим.
IT>Надеюсь, при мне это никогда не появится. Тем не менее, если тебе хочется поговорить о выразительности не на словах, а на деле, то мы можем с тобой посостязаться. Давай возьмём какой-нибудь PetShop и сравним код на булките и NH.
PetShop совершенно неинтересен. Это банальное классическое веб-приложение.

Ты лучше попробуй сделать так, чтобы изменения, которые ты делаешь с помощью Булкита, записывались в отдельную базу для аудита, а потом рассылались клиентам (с учётом ACL, невыразимых на уровне стандартных средств БД).

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

G>Ну тогда EF вообще lw/orm, только несколько просчетов не позволяют использовать его в этом качестве на полную катушку.

Значит не lw/orm

G> (кстати эти просчеты у EFv4 исправлены).

значит EFv4 можно использовать как LW/ORM (компенсация за застреленный linq2sql?).

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

КО>>Как фронтенд, я бы однозначно рекомендовал Silverlight 3 (www.silverlight.net) и WPF.
SHE>Вот такие интересности ждут Вас при выборе Silverlight-a в качестве базовой технологии для front-end-а enterprise level приложения (back-office-а и т.д.):

А я скажу пару слов в защиту.

SHE>- работать с ним из VS2008 мягко говоря неудобно... Другими словами забейте на удобства и пишите XAML ручками.

Верно. Но можно подумать в asp.net что-то иначе... На практике достаточно навороченую форму с табами, визардом и прочим в дизайнере тоже хрен откроешь.
Короче, ситуация абсолютно одинаековая: на более-менее простых формах всё Ок, на сложных — и там и там грабли.

SHE>- отладка. Вообщем-то очевидно — пока не скомпилишь — не запустишь. Забудьте про изменения "на лету", как в ASP.NET. Мелочь? Ето здорово кушает время — скомпилил, запустил, проверил, нашел ошибку, остановил, пофиксил, скомпилил, запустил...и т.д. по кругу.

Да ну, это не серьёзно. Разметка занимает дай бог процентов десять времени. И я реально забыл уже когда мне хотелось бы делать это в дизайнере.

SHE> К тому же в Silverlight-е есть ряд забавных конвенций — например Binding ошибки не считаются ошибками, и обнаружить их можно только тестируя приложение и тупо мониторя Output окошко

Есть более прогрессивные методы
http://bea.stollnitz.com/blog/?p=52

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

SHE>Пользователю надо комфортно работать с данными. Что предлагает Silverlight? CTRL-C в SL работает только в текст-боксах...
Идея через буфер себе странички сохранять достаточно странная. Нафига тогда вообще огород городить, если пользователю "комфортно работать с данными" не через ваш инструмент, а сохраняя страницу(куда?)?

SHE>проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту)
Вы чего, издеваетесь? HtmlPage.Window.Navigate(url, target) — хоть в новом, хоть в текущем... Может это в консерватории что-то не так?

Короче, всё совсем не так страшно, как вы это описываете. Тем более, что основная масса притензий вообще непонятно к чему: SL плохой, надо double-click допиливать, а html хороший, там... А как там этого достичь? Хаками js, попутно обходя грабельки особенностей разных броузеров?

Для меня лично есть одно достоинство SL, котрое перевешивает все недостатки. Я ПИШУ НА ОДНОМ ЯЗЫКЕ.
Как пишутся морды на ASP.net? Тут html, здесь — js, тут — dhtml, тут css, еще какая-то хрень... Блин, да на каком языке мы пишем?

" ASP.NET (или любой другой web framework)"? Это же html, шаг в право — шаг в лево: расстрел. Сделать дропдаун с чем-то кроме текста? Вот вам бубен. Надо карту/графики? Ой, это лучше вообще на чём-нибуть другом. Драг-энд-дроп? Тут где-то фреймфорк на js был... Многооконный интерфейс? Ну вы поняли

Сейчас потихоньку переводим проект с asp.net на sl — клиенты довольны. Оно и реально(хотя бы потому, что навороченые контролы со справочниками можно затянуть один раз вместо того, что-бы тащить их на каждый чих) и субьективно(проще в начале пододжать хоть минуту чем потом ждать двадцать раз по три секунды) начинает быстрее работать, да и пишется всё гораздо быстрее.
Каких контролов вам не хватает? Нас полностью удовлетворяет Silverlight Toolkit(это вроде как стандартный набор), ну DevExpress(он бесплатный пока) еще иногда.

В общем у нас идут в основном холивары между флешерами и sl, приверженцев asp.net+js как-то не осталось

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

C>PetShop совершенно неинтересен. Это банальное классическое веб-приложение.

Кто бы сомневался

C>Ты лучше попробуй сделать так, чтобы изменения, которые ты делаешь с помощью Булкита, записывались в отдельную базу для аудита, а потом рассылались клиентам (с учётом ACL, невыразимых на уровне стандартных средств БД).

Задача аудита совершенно ортогональна тому, чем должен заниматься ORM tool. И реализуется она в приложения с прямой архитектурой с помощью вызова одного метода на операцию в нужном месте, вроде:

public void Audit(string operation, string comment);

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

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

IT>Здравствуйте, Аноним, Вы писали:

А>>В чём принципиальная разница в использовании BLToolkit, NHibernete и FE?

IT>BLToolkit — это lightweight ORM. NH и FE — heavy ORM.

IT>Принципиальная разница между LW/ORM и H/ORM в том, что задача первых облегчить работу с реляционными данными, а вторых — заменить работу с реляционными данными на работу с объектной моделью. Из этого вытекают как достоинства, так и недостатки обоих подходов.

Но ведь и те и другие возвращают одинаковую коллекцию объектов. Какая-то быстрее, какая-то медленнее.
Етот нюанс не понятен.

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

C>>Ты лучше попробуй сделать так, чтобы изменения, которые ты делаешь с помощью Булкита, записывались в отдельную базу для аудита, а потом рассылались клиентам (с учётом ACL, невыразимых на уровне стандартных средств БД).
IT>Задача аудита совершенно ортогональна тому, чем должен заниматься ORM tool. И реализуется она в приложения с прямой архитектурой с помощью вызова одного метода на операцию в нужном месте, вроде:
IT>

public void Audit(string operation, string comment);

А как мы синтезируем строчку и операцию?

Ручками? -> У морг.

IT>То, что тебе удалось научиться забивать шурупы молотком очень похвально, но говорит лишь о том, что твой инструмент часть операций делает неявно, в тайне от программиста и нужно заниматься шаманством и стучать в бубен для того, чтобы заставить своё приложение выполнять простейшие операции типа аудита. Извини, но это просто смешно.
Оно у меня не для аудита нужно (это просто приятное дополнение), а для рассылки изменений клиентам. В реальном времени.

Т.е. я делаю так:

        //В дебрях сервера
    @Override public void setCustomProperty(Key usId, String prop, String value, String type)
    {
        User us=(User)dataHelper.loadForModify(ctx(), usId); //С учётом ACL!

        CustomProperty newProp=new CustomProperty();
        newProp.setParentUser(us);
        us.getCustomProperties().add(newProp);

        newProp.setName(prop);
        newProp.setValue(value);
        newProp.setType(type);
                //И ничего больше делать не надо!
       }

       //На клиентах
       public void consumeEvents(DiffBundle diff)
       {
             User us=getCurrentUser();
             if (diff.containsObject(us))
             {
                   Set<CustomProperty> props=us.getCustomProperties();
                   rebindProperties(props); //И пользователь видит изменённые данные. МГНОВЕННО.
             }
       }

Более того, клиенты не имеют доступа к БД _вообще_. Они полностью работают через слой реплицируемых объектов.

Как такое будешь делать?

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

C>Более того, клиенты не имеют доступа к БД _вообще_. Они полностью работают через слой реплицируемых объектов.
C>Как такое будешь делать?
Забыл сказать. Разные CustomProperty могут ещё иметь разные правила доступа, и для недопущенные пользователи просто не увидят то, что не могут видеть.

И оно всё написано один раз и работает для всех объектов, без дополнительных телодвижений с моей стороны. Т.е. я просто пишу обычный серверный код, даже не думая как оно там будет реплицироваться.

Здравствуйте, Аноним, Вы писали:

А>Но ведь и те и другие возвращают одинаковую коллекцию объектов. Какая-то быстрее, какая-то медленнее.
А>Етот нюанс не понятен.

Вопрос не в том, что они возвращают, а как они это делают. В случае с LW/ORM программист обращается за данными к БД с помощью LW/ORM. В H/ORM программист обращается непосредственно к H/ORM, а уж как там она работает с БД дело десятое.

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

G>кстати эти просчеты у EFv4 исправлены

Можно развить эту тему?

Что планируется изменить?

Есть ли ссылки?