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

А>Насколько я понял (а я немного покопал Ваш проект) то между BLToolkit и NHibernate разница намного большая, чем просто скорость работы. Я смотрю, что пипл юзающий BLToolkit, "люто ненавидит H/ORM" [(c) IT] потому что пытались применить его как "молоток к шурупу" [(с) IT].

Дело даже не в BLToolkit. BLT можно совершенно спокойно заменить на Linq2SQL и получится тоже самое.

А>И ежу понятно, что ежели у вас 400 запросов в секунду, то необходимо искать разумный компромисс между скоростью работы и удобством пользования. Этим компромисом является BLToolkit. Мне тяжело назвать "удобным" использование SQL при разработке приложений на C#.

Какая разница что тяжело называть "удобным", SQL или HQL или как там его? Текстуальные строки они и в африке текстуальные строки.

Если же речь идёт о Linq, то тут есть один момент. Честно говоря, после выхода Linq2SQL я подумывал о переходе ORM части проекта BLT в пассивный режим развития, т.к. L2S обладая очень приличной производительностью и при наличии провайдеров к другим базам данных мог бы оказаться практически идеальным LW/ORM решением в том числе и для меня. Но в MS решили по-другому и развивать L2S не стали. В результате я занялся поддержкой Linq в BLT несколько поздновато, как минимум на пару лет позже, чем конкуренты. Но работы идут, на сегодня поддержка Linq в BLT уже выше, чем в NH и всё идёт к тому, что она будет не хуже или даже лучше, чем в L2S. При этом всё будет работать быстрее и более чем с десятком баз данных. Так что упрёки в plain SQL я пока принимаю, но очень скоро эти разговоры можно будет закончить навсегда. Можно даже уже начинать пробовать

А>Я предполагаю, что дело не в мышлении, а в типе разрабатываемого ПО.

Тип ПО без разницы. Дело именно в скилсете разработчиков. Если в нём отсутсвуют навыки работы с реляционными данными, то выбор H/ORM вполне очевиден.

А>К примеру у нас удачно удалось применить наследование объектов и хранение таковых в БД посредством Гибернейта. Если суть разрабатываемого ПО состоит не в хрании данных, а в управлении внешними устройствами, моделировании процессов и т.д. (тут хранение данных не есть основой самого ПО и подход к проектированию иной нежели таблица и список) тогда заморачиваться SQL`ем чтобы ускорить время реакции интерфейса с 0,0001с до 0,00009с есть нецелесообразно, а местами еще и вредно. Посему заявления, что проект априори под угрозой только потому что под Гибернейтом, смешные.

Эти заявления не связаны с производительностью. Влад имел ввиду как раз архитектуру приложений, которая диктуется применением тяжёлых ORM. H/ORM диктует архитектуру приложения, это факт. И эта архитектура рано или поздно может стать проблемным местом. Обрати внимание на посты Cyberax. Все его "а ты так можешь" — это демонстрация смекалки по обходу именно такой архитектуры приложения. Его мозг зашорен Хайбернейтом и он даже представить не может, что тоже самое можно решать не просто, а очень просто, если избавиться от диктата архитектуры со стороны используемого инструмента. И в отличии от него, я свои приложения строю так, как считаю нужным я, а не мой инструмент. А мой инструмент в моих руках всего лишь помощник, но не диктатор.