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

А>А можно по-подробнее на ету тему.

На этом сайте эта тема обсуждалась уже много раз. Поиск должен помочь.

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

В двух словах — в идеологии. NHibernete и от части FE предлагают абстрагироваться от реляционной природы данных замаскировав БД под граф объектов. К сожалению ООП плохо подходит для обработки массивов данных. В нем для этого попросту нет средств. Работа с БД чрез интефейс объектов приводит к огромному оверхэду. Основная причина заключается в том, что ООП хорошо выглядит только если объекты лежат в памяти. Тогда начинаются разные навороты цель которых скрыть эти проблемы. Средства используются разные, но обычно все сводится к кэшированию. Ну, а кэширование, как не трудно догадаться противоречит массовм обновлениям данных с использованием UPDATE + сложное WHERE (а то и подзапросами, и джоинами).

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

Для обработки данных в BLToolkit предлагается всегда использовать запросы. Это могут быть или прямые обращения к СУБД на ее диалекте SQL, или (с недавнего времени) использование универсального языка LINQ. Сейчас автор BLToolkit-а (IT) заканчивает реализацию поддержки LINQ для BLToolkit. Он обещал, что к в него войдут и массовые обновления/вставки. Обещана поддержка широкого спектра СУБД.
Используя возможности BLToolkit-LINQ можно будет эффективно обрабатывать данные больших объемов самым естественным для этого образом и при этом быть независимым от конкретной СУБД (по желанию, конечно). При этом так же гарантируется, что работа с удаленными данными будет производиться практически так же эффективно как прямая работа с SQL.

А>Какое решение выбрать?
А>К сожалении при всём уважении к BLToolkit (результаты тестов видел, впечатляет) использовать его нет возможности поскольку к сожалению не мы ето определяем.

Если у вас есть возможность использовать NHibernete, то не понятно что может не дать использовать BLToolkit.

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

VD>BLToolkit предлагает смотреть на БД как на БД и всего лишь автоматизирует операции выборки данных и превращение строк в простые объекты. БД в этом случае представляется в виде списков объеденных реляционными отношениями. Объекты же всего лишь заменяют абстракцию записи (в широком смысле этого слова, т.е. некой структуры данных имеющей именованные поля).
Хотел было разобраться с тулкитом, но ... дела мирские.
Хочу рассказать еще о Гибернейте (мне кажется что это не сделаешь в БЛТулките)
Когда я проектирую бизнес-логику, я делаю как это учил Фаулер — сначала определяюсь с бизнес-объектами. Затем, я эти объекты реализую на языке программирования и... вуаля расставляю атрибуты и создаю структуру БД на сервере БД. Меняю бизнес-логику — пересоздаю програмно структуру БД, очень удобно. Пока скорость работы удовлетворяет, не имею ни малейшего желания усложнять себе жизнь. Хотя, БЛТулкит конечно же поковыряю.

VD>Если у вас есть возможность использовать NHibernete, то не понятно что может не дать использовать BLToolkit.
Дабы избедать таких ситуаций
http://rsdn.ru/forum/prj.rsharp/2347688.flat.aspx#2347688

Автор: Щербатов Евгений
Дата: 13.02.07

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

А>Мне не доводилось писать бизнеслогику где бы требовались груповые изменения. В основном объект туда, объект сюда

Скорее всего это потому, что ты думаешь в императивном стиле.
Мне вот никогда не доводилось видеть бизнес данные состоящие из отдельных объектов. Всегда, почему-то, попадались списки или таблицы.

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

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

А>>Мне не доводилось писать бизнеслогику где бы требовались груповые изменения. В основном объект туда, объект сюда

VD>Скорее всего это потому, что ты думаешь в императивном стиле.
VD>Мне вот никогда не доводилось видеть бизнес данные состоящие из отдельных объектов. Всегда, почему-то, попадались списки или таблицы.

Таблица — это массив объектов У каждого объекта могут быть связи с другими — это либо ссылка на другой объект либо массив объетов с лейзилоадами.

Груповое изменение данных мне приходилось часто делать в ОДБ — там проведение документов, овердрафтов и тому подобной дряни хватало. Но ведь не все приложения — это отчеты для баб из бухгалтерии ) извините если кого обидел. Бывают проекты, где записей в бд итого несколько сотен, но каждая запись на вес золота. Например ты хранишь показания прибора за некий интревал времени. Показания — это wav размером нескольно десятков мегабайт + некоторые метаданные. Вот тут то лейзилоады то что доктор прописал.

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

VD>>Скорее всего это потому, что ты думаешь в императивном стиле.
VD>>Мне вот никогда не доводилось видеть бизнес данные состоящие из отдельных объектов. Всегда, почему-то, попадались списки или таблицы.

А>Таблица — это массив объектов ;-)

Вау! В смысле — уж ты!

Не вспомнишь определение понятия массив?
И, кстати, почему объектов?

А> У каждого объекта могут быть связи с другими — это либо ссылка на другой объект либо массив объетов с лейзилоадами.

Ты про реляционную теорию что-то слышал?

А>Груповое изменение данных мне приходилось часто делать в ОДБ — там проведение документов, овердрафтов и тому подобной дряни хватало. Но ведь не все приложения — это отчеты для баб из бухгалтерии ) извините если кого обидел. Бывают проекты, где записей в бд итого несколько сотен, но каждая запись на вес золота.

Зачем же сотню записей пихать в БД, да еще и в виде объектов ее представлять?
Может проще было бы, действительно, массив объектов сделать?

А> Например ты хранишь показания прибора за некий интревал времени. Показания — это wav размером нескольно десятков мегабайт + некоторые метаданные. Вот тут то лейзилоады то что доктор прописал.

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

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

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

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

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

Главный недостаток LW/ORM в том, что он требует от праграммиста навыков работы с реляционными данными. Т.е. проблемы LW/ORM — это прежде всего проблемы квалификации программиста. Если же программист обладает всеми необходимыми навыками, то близость к БД плавно переходит из разряда недостатков в главное достоинство и LW/ORM становится практически идеальным решением. Это, кстати, хорошо заметно по нашему форуму. Как правило те, кто является экспертами в БД, рьяно защищают LW/ORM и люто ненавидят H/ORM.

Недостатки H/ORM так же вытекают из их достоинств. Представление реляционных данных в виде объектой модели не может быть бесплатным удовольствием по определению. Но самое неприятное то, что это практически не заметно на несложных задачах. Но, как говорится, чем дальше в лес, тем жирнее партизаны. В конце концов, нежелание/неумение работать с реляционными данными вообще со времененм компенсируется экспертными знаниями в борьбе против конкретной H/ORM в частности.

Но выбор остаётся, естественно, за программистом. Если вы не очень уверенно чувствуете себя в работе с реляционными данными, то, возможно, H/ORM будет лучшим выбором. А со временем, подкачав навыки работы с БД, можно будет перейти на LW/ORM.

Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.

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

IT>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.

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

IT>>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
C>Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.

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

Здравствуйте, Кирилл Осенков, Вы писали:

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

— работать с ним из VS2008 мягко говоря неудобно. Мало того что дизайнер примитивный (и если пользуетесь Expression Blend, то ето переодическое переключение окон тормозит и достает), так он еще и откровенно глючит, а не дай бог подключить сторонние Silverlight контролы — напрочь отказывается что либо вырисовывать. Ну и из-за специфики XAML иногда ето просто невозможно. Например, для безразмерного контрола значения Width и Height опускаются (в Expression Blend есть спец. аттрибуты DesignWidth и DesignHeight, которые есс-но игнорируются VS). Другими словами забейте на удобства и пишите XAML ручками.

— отладка. Вообщем-то очевидно — пока не скомпилишь — не запустишь. Забудьте про изменения "на лету", как в ASP.NET. Мелочь? Ето здорово кушает время — скомпилил, запустил, проверил, нашел ошибку, остановил, пофиксил, скомпилил, запустил...и т.д. по кругу. А как иначе проверить как выглядит твое творение? (помним про предыдущий пункт — дизайнер ничего не показывает, а XAML пишем руками — надо же посмотреть что из етого получилось ) К тому же в Silverlight-е есть ряд забавных конвенций — например Binding ошибки не считаются ошибками, и обнаружить их можно только тестируя приложение и тупо мониторя Output окошко

— контролы контролы контролы... Стандартных не хватает. Сторонние — глючат!!! Работал с Telerik, DevExpress — просто не верится, что такие уважаемые компании выкидывают на рынок такое <здесь нехорошее слово>. Впечатление удручающее, когда приложение падает на ровном месте с кодом, взятым из примера Demo. Или просто контрол не перерисовывается в окне. Сделали броузеру minimize/maximize, а на месте контрола пустое место Здесь нужно вооружиться терпением и ждать пока пофиксят. Из бесплатных — Silverlight Toolkit — нареканий нет. Но вообщем-то выбор не большой. Пока. Наверно надо подождать...

— библиотеки. Иногда ето больно Потому как после WPF кажется, что Silverlight ето ампутированный обрезанный поделок. Спотыкаешься буквально на каждой мелочи. До чертиков читать форумы, что етой-де фишки пока в Silverlight нету, но вот вам пожалуйста почти такой же работающий лисапедик. Чего только стоит эмуляция дабл клика мыши

Ну и вот другие мелочи:
— нет XML/XSLT (есть Linq To Xml — пользуйтесь)
— проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту) и URL mapping-ом (SL3 предлагает solution, правда примитивный но какой никакой)
— проблемно с экспортом данных вообще
Никогда не задумывались насколько удобна HTML страничка?
А вот настолько:
+ Copy/Paste любого контента в любое приложение — без проблем, с сохранением стилей или без
+ Сохранить на диск — в виде HTML, TXT, MHT (веб архив, со всеми картинками) — без проблем
+ Export таблиц — прямо в Excel (из IE, если установлен Office)
Пользователю надо комфортно работать с данными. Что предлагает Silverlight? CTRL-C в SL работает только в текст-боксах... Делать screenshot-ы?

Можно ли как-то подружить SL с HTML? да, как-то. Ето стоит лишних усилий и постоянных напрягов фантазии. Вообщем не скучно. А посмотрите насколько уродлив HTML контрол для SL от Telerik

Ну и в конце концов не забываем, что Silverlight — client-side приложение.
Любой unhandled exception приводит к crash-у всего приложения.
Там где для html-я надо просто нажать F5, в SL ето тот же F5 только с перезагрузкой всей аппликухи.
А интеграция с серверными решениями (тот же reporting) ето как правило геморрой тот еще.

Вообщем я для себя сделал выводы насчет пригодности SL для написания бизнес приложений. ASP.NET (или любой другой web framework) + c элементами SL = да.
SL как базовый framework — никогда, по крайней мере пока сильные форума сего не рассеют мои невеселые впечатления своими рецептами правильного приготовления современного web приложения на основе технологии Silverlight

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

IT>>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
C>Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.

Если под размером задач понимается объем обрабатываемых данных, то несомненно лучше.

Вообще не верно называть продукты вроде гибернэйта H/ORM-ами. Более точно их назвать Object Persister-ами, так как именно эта идеология подводится под них.

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

IT>>>Так же следует отметить, что бытует мнение, будто H/ORM лучше подходят для больших и сложных задач, а LW/ORM для маленьких и простых. Это заблуждение.
C>>Так же следует отметить, что бытует мнение, будто L/ORM лучше подходят для больших и сложных задач, а HW/ORM для маленьких и простых. Это заблуждение.
IT>Ну да, от перемены букв местами суть не меняется. По делу есть что сказать?
Просто для полноты. Ну или можно очередной флейм устроить ORM vs. L/ORM. Мне лично лень.

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

C>Просто для полноты. Ну или можно очередной флейм устроить ORM vs. L/ORM. Мне лично лень.

А что его устраивать то? Факты на лицо. Иди сначала поправь тесты гибернэта так чтобы они хотя бы сравнялись с булкитовскими, тогда можно будет еще раз пофлэймить.

Потом с тобой не интересно флэймить. Ты рано или поздно начинаешь всем объяснять, что просто используешь некий сабсэт гибернэйта как эдакий L/ORM. Так что с одной стороны ты споришь с нами, но с другой находишся практически на тех же позиция. Ну, а твои сказки про скорость гибернэйта как-то не стыкуются с результатами тестов.

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

VD>Вообще не верно называть продукты вроде гибернэйта H/ORM-ами. Более точно их назвать Object Persister-ами, так как именно эта идеология подводится под них.

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

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

C>>Просто для полноты. Ну или можно очередной флейм устроить ORM vs. L/ORM. Мне лично лень.
VD>А что его устраивать то? Факты на лицо. Иди сначала поправь тесты гибернэта так чтобы они хотя бы сравнялись с булкитовскими, тогда можно будет еще раз пофлэймить.
"Иди перепиши Nemerle, чтоб всегда работал быстрее кода на С"

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

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

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

Тебе ничем. Коси траву в противогазе ибо так труднее. )))
Юзайте, дети мои, то что вашей душе угодно.
Для топикстартера информации достаточно, разве что порекомендую Мартина Фаулера "Архитектура корпоративных программных приложений" пролистать. Похоже что топикстартер программист с опытом — определиться с выбором сам сможет. А ДАО на sql и самому можно написать.

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

IT> Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM

А куда тогда linq2sql приткнуть? LW/ORM с элементами H/ORM?

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

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

Фу, какой бездарный слив.

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

IT>> Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM

AVK>А куда тогда linq2sql приткнуть? LW/ORM с элементами H/ORM?

Я бы приткнул к LW/ORM, не смотря на глупости от H/ORM.

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

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

IT>> Можно начать хотя бы разделять ORM тулы по классам: H/ORM и LW/ORM

AVK>А куда тогда linq2sql приткнуть? LW/ORM с элементами H/ORM?

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

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

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

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