powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / Data Access Layer
25 сообщений из 63, страница 2 из 3
Data Access Layer
    #34513484
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
То, что одним селектом-это замечательно(Hibernate не стоит на месте).Присовокупим к счету еще оплаты, которые по нему проводились и комментарии(все лежит в отдельных таблицах).В этом случае одним запросом можно будет обойтись?
Под произвольным количеством подразумевается случай, когда необходимо сделать поиск с соединением, скажем таблиц шести, по произвольному набору полей выборки и вернуть только нужную страницу с сортировкой по одному полю.Как в Hibernate будете с этим бороться?
Кэширование упоминалось для ad-hoc запросов на стороне БД.С большим количеством join'ов и параметром это не работает.Парсить запрос и делать генерацию плана выполнения-удовольствие весьма накладное.
Кэшировать данные на стороне клиента не всегда возможно.
То, что Hibernate не поддерживает всех возможностей конкретной БД(туже постраничную выборку), возражений, я думаю, не будет?
...
Рейтинг: 0 / 0
Data Access Layer
    #34513547
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaПрисовокупим к счету еще оплаты, которые по нему проводились и комментарии(все лежит в отдельных таблицах).В этом случае одним запросом можно будет обойтись?
Можно. Только база-то не нагнется :) ?
SeVa
Под произвольным количеством подразумевается случай, когда необходимо сделать поиск с соединением, скажем таблиц шести, по произвольному набору полей выборки и вернуть только нужную страницу с сортировкой по одному полю.Как в Hibernate будете с этим бороться?
Тут либо Criteria API либо ручной HQL/SQL, поскольку серебряной пули нет, как известно.
SeVa
Кэширование упоминалось для ad-hoc запросов на стороне БД.С большим количеством join'ов и параметром это не работает.Парсить запрос и делать генерацию плана выполнения-удовольствие весьма накладное.
Бесспорно. Но ведь и в вашем случае -- в случае рукописных запросов -- БД придется выполнять те же самые действия. Я же имел в виду кэширование текста SQL для ad-hoc запросов внутри самого NH.
SeVa
То, что Hibernate не поддерживает всех возможностей конкретной БД(туже постраничную выборку), возражений, я думаю, не будет?
Всех специфичных возможностей естественно не поддерживает (те же хинты). Про пейджинг не скажу, ибо не пользовался.
...
Рейтинг: 0 / 0
Data Access Layer
    #34513665
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1.База быстрее загнется от кучи мелких запросов.
2.Используются только процедуры с готовыми планами выполнения.

Допускаю, что для блогов с отсутствием бизнес логики, прав доступа и тд, Hibernate-нормальный вариант, как и MySql без транзакций.Но я уже с ним наелся.Вкус и цвет у всех разные, посему на этом точка.
...
Рейтинг: 0 / 0
Data Access Layer
    #34513703
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa2.Используются только процедуры с готовыми планами выполнения.
Хибернейт и с ними научили работать.
SeVaДопускаю, что для блогов с отсутствием бизнес логики, прав доступа и тд, Hibernate-нормальный вариант, как и MySql без транзакций.Но я уже с ним наелся.Вкус и цвет у всех разные, посему на этом точка.
Перед точкой скажу, что сейчас NH используем в промышленном проекте -- если по количественным характеристикам, то это 130+ классов и 170+ Кб XML'я, их описывающего и больше 350 Кб кода самих бизнес-объектов. БД тоже немаленькая -- в настоящий момент около 120 Гб.
...
Рейтинг: 0 / 0
Data Access Layer
    #34514140
Sa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
buser
А Вы в своих проектах что для постраения DAL/BIZ используете?

Ничего коммерческого или бесплатного.
присматриваюсь к nHibernate, слежу за развитием LINQ.

Код: plaintext
 uid  =  S a

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Data Access Layer
    #34518866
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На досуге решил посмотреть, что нового в Hibernat'e,почитал доки, погуглил и нашел в форуме rsdn такой пост:

NHibernate for .NET - хорошая ORM ?

Так случилось, что для NHibernate тоже приходится писать много своего кода на реальном большом проекте.

V>Если не секрет,
V>подпорки кокого типа вы писали ?

Всего и не упомнишь. Постараюсь вспомнить кое-что:


Свои персистеры.

Свои проперти аксесоры (захотелось использовать generic-коллекции, а NHibernate для 1.1; также иногда хотелось сохранять NULL для default value-type value и т.д.).

Свой кеш-провайдер (захотелось юзать query notifications, а NHibernate ничего про MS SQL Server 2005 не знает).

Код, модифицирующий запросы, генерируемые NHibernate. Иногда приходилось прибегать к "ручному" постпроцессингу сгенерированного запроса в строковом (!) виде, т.к. иначе не получалось.

Код, позволяющий загружать BO, используя свой произвольный SQL и/или хранимые процедуры.

Код, позволяющий выполнять несколько HQL-запросов на чтение в одном database roundtrip.

Свой механизм вызова обработчиков до/после выполнения CRUD-операций — IInterceptor и ILifecycle не подошли потому, что в них или не всё отловишь, или сессию нельзя использовать и т.д.

Больше не помню

PS: Оно, конечно, с виду кажется немного, но на деле нужно было время, чтобы понять, что это нам действительно нужно, понять, как это можно реализовать, и реализовать


Их бы усилия да в мирных целях.
На мой взгляд ORM - это непрозрачная стена между разработчиком и БД, посему приходится мастерить стремянки, чтобы через нее перелезть.Для тех, кто девочку с именем БД и в глаза не видел-вполне достойный вариант.Я же с дамами предпочитаю общаться не в электронном виде, а носить их на собственных руках,тогда они более послушные и отзывчивые.
...
Рейтинг: 0 / 0
Data Access Layer
    #34519264
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaНа мой взгляд ORM - это непрозрачная стена между разработчиком и БД, посему приходится мастерить стремянки, чтобы через нее перелезть.Для тех, кто девочку с именем БД и в глаза не видел-вполне достойный вариант.Я же с дамами предпочитаю общаться не в электронном виде, а носить их на собственных руках,тогда они более послушные и отзывчивые.
Вы сами-то пользовались хотя бы одной ORM? Тем же NHibernate?
...
Рейтинг: 0 / 0
Data Access Layer
    #34519567
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, грешен(почти 3 года).Hibernate неплохой продукт, но со своими ограничениями.Меня больше устраивают варианты, где у меня руки ничем не связаны, как в том же CSLA.Есть любители и там, которые с данными работают через Hibernate!!!Полная свобода, вы можете сами выбирать каким образом осуществлять доступ к БД.Hibernate-тоталитаризм.Делаем, как я умею, иначе-расстрел.
Общим строем ходить я никогда не любил.
...
Рейтинг: 0 / 0
Data Access Layer
    #35062046
Фотография webus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaДа, в SCSF большая куча кода, но именно это в купе с reflection, позволяет затрачивать минимум калорий при разработке, что на мой вгляд, более существенно, чем подсчет милисекунд.
Например:

[CreateNew]
public MyPresenter Presenter
{
set
{
_presenter = value;
_presenter.View = this;
}
} // при создании View(презантационного слоя) автоматически создается Presenter(обработчик событий)
в свою очередь, в нем на автомате создается сервис

private IMyService _myService = null;

[InjectionConstructor]
public Presenter
(
[ServiceDependency] IMyService MyService
)
{
_myService = MyService;
}

Кратко,внятно и не нужны никакие файлы конфигурации.
Еще пример.Привязка комманды к пункту меню

private void ExtendMenu()
{
ToolStripMenuItem item = new ToolStripMenuItem("My Menu Item");
WorkItem.Parent.UIExtensionSites["Tools"].Add(item);

WorkItem.Commands[CommandNames.ShowMyItem].AddInvoker(item, "Click");
}

Обработчик события

[CommandHandler(CommandNames.ShowMyItem)]
public void MenuToolsMyMenuItem_Click(object sender, EventArgs e)
{
IMyView myView = GetOrCreateWorkItemElement<MyView>("MyView");
WorkItem.Workspaces[Constants.WorkspaceNames.MDIWorkspace].Show(myView);
// сервис и presenter уже создаются на автомате
}

У нас основные 3 вида View используются в 10 модулях практически в 99%.Они создаются только один раз, что резко повышает производительность.
Благодаря reflection просто решается проблема с правами доступа.Грузятся только те модули, на которые есть доступ,автоматически деактивируются комманды, события, визуальные элементы и тд.

Что касается Hibernate, у него тоже есть свои накладные расходы: все тот же reflection, динамическая генерация sql запросов, создание proxy и самое главное-убогая работа с БД.Ручками я заточу запросы гораздо лучше, чем решения на все случаи жизни, это уже проверено.

PS
Все сахера расписывать долго.
PSS
Это моя точка зрения и я не навязываю ее с фанатизмом другим.Везде есть свои плюсы и минусы.

очень интересна технология SCSF
где про нее почитать подробнее
...
Рейтинг: 0 / 0
Data Access Layer
    #35062235
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Data Access Layer
    #35076459
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Нахлобуч
В CSLA Reflection не "по всякому поводу", а только для MessageRouter-паттерна (DataPortal) в котором 4-5 методов всего лишь.
К тому же ничто не мешает закешировать MethodInfo в какой-либо реализации паттерна Registry, если есть большие опасения по поводу рефлексии, и отдача от этого кеша думаю будет куда лучше чем от кеширования разобранных HQL-запросов в NHibernate.
Я тоже после долгих мытарств в сторону NHibernate, XPO, BLToolkit, пришел к выводу что для меня CSLA это оптимальный вариант. В CSLA в плане полноценного rich-BO layer-a намного больше сделано, хоть и есть несколько мест которые мне мало нравятся.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076473
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ДынникВ CSLA Reflection не "по всякому поводу", а только для MessageRouter-паттерна (DataPortal) в котором 4-5 методов всего лишь.
А так же для заполнения объектов данными, для n-level undo и для кучи остальной требухи.
Роман Дынник
К тому же ничто не мешает закешировать MethodInfo в какой-либо реализации паттерна Registry, если есть большие опасения по поводу рефлексии, и отдача от этого кеша думаю будет куда лучше чем от кеширования разобранных HQL-запросов в NHibernate.
Ну вы и сравнили. Не ясно, во-первых, почему вас так напрягает кэширование HQL'я. Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :)
Роман Дынник
Я тоже после долгих мытарств в сторону NHibernate, XPO, BLToolkit, пришел к выводу что для меня CSLA это оптимальный вариант. В CSLA в плане полноценного rich-BO layer-a намного больше сделано, хоть и есть несколько мест которые мне мало нравятся.
"BO-layer" не должен быть rich в том смысле, что там должно быть как можно меньше функционала.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076522
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нахлобуч
Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :)

хм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша? вопрос в том как вы решаете пробелму сортировки и фильтрации по различным полям, ведь кроме ID мало чего известно. Как я понимаю запрос вида select id, value from table where value like '%asd%' hibernate не может предсказать и вынуть из кеша, и полюбому вытянет все из базы?:) кеш хорошо работет в единичных случаях. Если, например, много логики в хранимках, то кеш приходится вырубать.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076573
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зыхм, наверное поэтому ваш PM, как вы описывали, принял решение оперировать и разбивать на странице списки ID, чтобы таскать данные из кеша?
У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю
зы
вопрос в том как вы решаете пробелму сортировки и фильтрации по различным полям, ведь кроме ID мало чего известно.
Пока никак, но в планах есть. Будем перетряхивать.
зы
Как я понимаю запрос вида select id, value from table where value like '%asd%' hibernate не может предсказать и вынуть из кеша, и полюбому вытянет все из базы?:)
Почему же? Вполне сможет.
зы
кеш хорошо работет в единичных случаях. Если, например, много логики в хранимках, то кеш приходится вырубать.
Ну уж "единичных"... У нас система при упавшей БД работала (не целиком, конечно) около 40 минут только за счет кэша второго уровня.

И вообще -- мы об одном и том же кэше разговариваем?
...
Рейтинг: 0 / 0
Data Access Layer
    #35076663
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я уверен да :)
интересен алгоритм хибернейта по предсказанию результатов выборки, при условии, что параметры запроса ранее не встречались.
вообще кеш конечно хорошо, это пожалуй один из немногих весомых плюсов от его монстроидальности.

автор
У нас объемы сравнительно большие -- в среднем по 200К "строк" на запрос, и редкий пользователь просматривает первую тысячу. И поэтому не было смысла выгружать объекты целикомю
не очень понятен смысл вытаскивать 200K строк, если пользователь не смотрит больше 100. В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать?
...
Рейтинг: 0 / 0
Data Access Layer
    #35076691
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зыинтересен алгоритм хибернейта по предсказанию результатов выборки, при условии, что параметры запроса ранее не встречались.
Само собой сам он ничего не гадает. Не было такого набора параметров -- он полезет в БД.
зы
не очень понятен смысл вытаскивать 200K строк, если пользователь не смотрит больше 100.
Это к начальству :) Впечатление производим -- мол, вона сколько у нас найдено...
зы
В чем тогда фишка не использовать пейджинг скуль сервера? в том, что хибернейт не знает, как это правильно и быстро сделать?
Не Хибернейт, а сам сиквель. Он с ума сходит -- в поисковых таблицах меньше 120 миллионов записей редко бывает.
...
Рейтинг: 0 / 0
Data Access Layer
    #35076754
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и сколько памяти отжирает приложение, если не секрет? точнее сколько отжирает кеш второго уровня, если его можно подсчитать отдельно :)
...
Рейтинг: 0 / 0
Data Access Layer
    #35076799
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зыи сколько памяти отжирает приложение, если не секрет? точнее сколько отжирает кеш второго уровня, если его можно подсчитать отдельно :)
Вот сейчас посмотрел -- самый жирный w3wp.exe на сервере по Task Manager'у занимает 250 Мб. Б о льшая часть -- кеш.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079358
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нахлобуч, при вытягивании 200К записей накладные расходы на reflection тикто и не заметит.
При правильно спроектированной БД, 120м записей для MS SQL - это семечки, если не вытаскивать почти всю БД за раз.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079378
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaНахлобуч, при вытягивании 200К записей накладные расходы на reflection тикто и не заметит.
А нет никакого рефлекшена.
SeVa
При правильно спроектированной БД, 120м записей для MS SQL - это семечки, если не вытаскивать почти всю БД за раз.
120 миллионов -- это в денормализованных поисковых таблицах. При показе данные выгружаются из нормализованных таблиц, причем граф получается довольно развесистый.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079569
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я к тому, что рассуждать о вреде рефлексии при таких выборках, по крайней мере-нелогично.
Накладные расходы на нее в таких случаях ничтожны.
Выводы о том, что CSLA плохо потому,что я так сказал, мало убедительны.
...
Рейтинг: 0 / 0
Data Access Layer
    #35079682
ъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ъ
Гость
НахлобучСамо собой сам он ничего не гадает. Не было такого набора параметров -- он полезет в БД.
а откуда он был, такой набор параметров? юзер не находит что искал и начинает долбить по 2тыс страницам? нахрен нужен такой сервис.
с какой вероятностью попадаете в кеш?
...
Рейтинг: 0 / 0
Data Access Layer
    #35080110
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучНу вы и сравнили. Не ясно, во-первых, почему вас так напрягает кэширование HQL'я. Во-вторых, по отдача от кеширования результатов запросов будет настолько значительной, что глядя на все это CSLA будет тихо плакать в сторонке :)

Как она будет плакать? кешированный HQL можно сравнивать с кешированнием вызовов хп (в CSLA). Так что тут либо никакой разницы, либо CSLA быстрее на этом этапе.
А кеширование MethodInfo (кеширование нескольких делегатов) по механизму быстрее чем разбор и кеширование HQL - выражений.
В CSLA 3.5 рефлексия будет заменена динамическими сборками.

Нахлобуч
"BO-layer" не должен быть rich в том смысле, что там должно быть как можно меньше функционала.
Это спорное филосовское утверждение.
Делаем POCO/POJO - получаем слабосвязанный и легко переносимый (что плюсы), но плохо инкапсулированный код (что несомненно минус) с недостаточным функционалом.
В плане передачи между слоями что POCO, что rich - без разницы - все решается настройкой сериализации.
...
Рейтинг: 0 / 0
Data Access Layer
    #35080118
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кеш-кеш...
сложна реализация не самого кеша (что есть всего лишь IdentityMap+Registry), а управления им - кеширование отдельных классов, время кеширования, память отводимая под кеш и чистка кеша в соответствии с ограничениями, слабые ссылки и т.п.
Я не специалист в NHibernate, поэтому мне интересно как он справляется с этим управлением?
Что имеется ввиду под кешем второго уровня?
Я всегда считал что кеш второго уровня - это UnitOfWork, т.е. по сути дела клиентский кеш в рамках сессии, а кеш первого уровня - это AppServer-кеш.
И по-моему, в этом контексте, сложна реализация именно кеша первого уровня.
...
Рейтинг: 0 / 0
Data Access Layer
    #35080183
зы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Дынник
Я всегда считал что кеш второго уровня - это UnitOfWork, т.е. по сути дела клиентский кеш в рамках сессии, а кеш первого уровня - это AppServer-кеш.
И по-моему, в этом контексте, сложна реализация именно кеша первого уровня.
можно сказать что на самом деле все наоборот
http://www.devx.com/dbzone/Article/29685 (первая ссылка из гугля)
...
Рейтинг: 0 / 0
25 сообщений из 63, страница 2 из 3
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / Data Access Layer
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]