Здравствуйте, Tom, Вы писали:
Tom>Да, абсолютно согласен, ещё я хочу отмести тех кто не позволяет гибко управлять генерацией C#/SQL. И тех у кого нет будущего. Тоесть Linq2Sql/EF тоже похоже уходят. По крайней мере Linq2Sql на 90% отметается
Вобщем-то NHibernate получается довольно неплох, кроме того, что кеш первого уровня у него отключить проблематично (хотя я не могу придумать зачем, кроме экономии памяти). Поддержку связей, коллекций и т.п. можно просто не использовать. Есть linq провайдер, правда не полный, некоторые запросы создать на нем в принципе невозможно. Впрочем для сложных запросов я бы использовал чистый сиквел или hql. Язык запросов почти идентичен сиквелу и почти идентичный сиквел и генерирует. Т.е. сюрпризов со странными запросами к базе без связей, коллекций и lazy load'а не будет.
Осталось руками сделать тестовое приложение и выбрать генератор который нагенерит по базе то, что получилось.
Z>Вобщем-то NHibernate получается довольно неплох, кроме того, что кеш первого уровня у него отключить проблематично (хотя я не могу придумать зачем, кроме экономии памяти).
А нафик он нам нужен. Что у насм будет — это свой кэш на основе SqlDependency. При этом естественно что SqlDependency будет создаваться на список обьектов, а не на каждый обьект своя.
Z>Поддержку связей, коллекций и т.п. можно просто не использовать. Есть linq провайдер, правда не полный, некоторые запросы создать на нем в принципе невозможно. Впрочем для сложных запросов я бы использовал чистый сиквел или hql. Язык запросов почти идентичен сиквелу и почти идентичный сиквел и генерирует. Т.е. сюрпризов со странными запросами к базе без связей, коллекций и lazy load'а не будет.
Z>Осталось руками сделать тестовое приложение и выбрать генератор который нагенерит по базе то, что получилось.
осталось хотя бы прочитать доки вводные по всем тулам, сделать матрицу по оценке их и провести эту самую оценку. Уфффф ((((
нехватает таких статей обзорных в интернете конечно
Здравствуйте, Tom, Вы писали:
Z>>Вобщем-то NHibernate получается довольно неплох, кроме того, что кеш первого уровня у него отключить проблематично (хотя я не могу придумать зачем, кроме экономии памяти). Tom>А нафик он нам нужен. Что у насм будет — это свой кэш на основе SqlDependency. При этом естественно что SqlDependency будет создаваться на список обьектов, а не на каждый обьект своя.
Z>>Поддержку связей, коллекций и т.п. можно просто не использовать. Есть linq провайдер, правда не полный, некоторые запросы создать на нем в принципе невозможно. Впрочем для сложных запросов я бы использовал чистый сиквел или hql. Язык запросов почти идентичен сиквелу и почти идентичный сиквел и генерирует. Т.е. сюрпризов со странными запросами к базе без связей, коллекций и lazy load'а не будет.
Z>>Осталось руками сделать тестовое приложение и выбрать генератор который нагенерит по базе то, что получилось. Tom>осталось хотя бы прочитать доки вводные по всем тулам, сделать матрицу по оценке их и провести эту самую оценку. Уфффф (((( Tom>нехватает таких статей обзорных в интернете конечно
ну вот как раз и будет обзор не забудьте поделиться результатами
Здравствуйте, Tom, Вы писали:
Z>>Вобщем-то NHibernate получается довольно неплох, кроме того, что кеш первого уровня у него отключить проблематично (хотя я не могу придумать зачем, кроме экономии памяти). Tom>А нафик он нам нужен. Что у насм будет — это свой кэш на основе SqlDependency.
Там в сессии хранится что-то типа хеша (Type, PK) -> (object obj, object[] propertyValues).
ID -> obj обеспечивает единичность экземпляра в рамках одной сессии (я использую сессии длиной в транзакцию).
ID -> propertyValues хранит копию данных из базы до маппинга для dirty checking, от него можно отказаться используя StatelessSession, но она вообще не умеет сохранять объекты.
Tom>осталось хотя бы прочитать доки вводные по всем тулам, сделать матрицу по оценке их и провести эту самую оценку. Уфффф ((((
Вобщем-то они сильно разные по для составления матрицы. Речь идет о выборе идеологии, а разные идеологии в одну матрицу ложатся плохо. Так что по дню на каждый фреймворк для написания небольшого тестового приложения будут совсем не лишними.
P.S. Если не секрет, чем не угодили BLToolkit и iBatis?
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Tom, Вы писали:
Tom>>Да, абсолютно согласен, ещё я хочу отмести тех кто не позволяет гибко управлять генерацией C#/SQL. И тех у кого нет будущего. Тоесть Linq2Sql/EF тоже похоже уходят. По крайней мере Linq2Sql на 90% отметается
Z>Вобщем-то NHibernate получается довольно неплох, кроме того, что кеш первого уровня у него отключить проблематично
Stateless сессии уже есть в NHibernate 2.0
Z>(хотя я не могу придумать зачем, кроме экономии памяти).
Stateless сессия может быть полезной, например, для вставки большого объема данных.
Здравствуйте, Tom, Вы писали:
Z>>Вобщем-то NHibernate получается довольно неплох, кроме того, что кеш первого уровня у него отключить проблематично (хотя я не могу придумать зачем, кроме экономии памяти). Tom>А нафик он нам нужен. Что у насм будет — это свой кэш на основе SqlDependency. При этом естественно что SqlDependency будет создаваться на список обьектов, а не на каждый обьект своя.
Z>P.S. Если не секрет, чем не угодили BLToolkit и iBatis?
iBatis пока вообще незнаю что такое, добавлю в список.
BLToolkit — своей генерилки entity нет как я понимаю.
Потом я не совсем представляю как аргументировать его использование перед начальством.
Если его использовать — то надо генерить код не на лету в runtime а в compile time.
В общем выбор то пока не сделан, так что все аргументя рассматриваются
Здравствуйте, Tom, Вы писали:
Z>>P.S. Если не секрет, чем не угодили BLToolkit и iBatis? Tom>iBatis пока вообще незнаю что такое, добавлю в список.
Tom>BLToolkit — своей генерилки entity нет как я понимаю. Tom>Потом я не совсем представляю как аргументировать его использование перед начальством. Tom>Если его использовать — то надо генерить код не на лету в runtime а в compile time. Tom>В общем выбор то пока не сделан, так что все аргументя рассматриваются
Там есть тулза. Её в Post Build пихаешь и всё в компайл-тайм генерится.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, Tom, Вы писали:
Z>>>P.S. Если не секрет, чем не угодили BLToolkit и iBatis? Tom>>iBatis пока вообще незнаю что такое, добавлю в список.
Tom>>BLToolkit — своей генерилки entity нет как я понимаю. Tom>>Потом я не совсем представляю как аргументировать его использование перед начальством. Tom>>Если его использовать — то надо генерить код не на лету в runtime а в compile time. Tom>>В общем выбор то пока не сделан, так что все аргументя рассматриваются
AS>Там есть тулза. Её в Post Build пихаешь и всё в компайл-тайм генерится.
Да и T4 в студии есть. По метаданным все что угодно сгенерить можно.
Re[10]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Здравствуйте, Tom, Вы писали:
Z>>>>P.S. Если не секрет, чем не угодили BLToolkit и iBatis? Tom>>>iBatis пока вообще незнаю что такое, добавлю в список.
Tom>>>BLToolkit — своей генерилки entity нет как я понимаю. Tom>>>Потом я не совсем представляю как аргументировать его использование перед начальством. Tom>>>Если его использовать — то надо генерить код не на лету в runtime а в compile time. Tom>>>В общем выбор то пока не сделан, так что все аргументя рассматриваются
AS>>Там есть тулза. Её в Post Build пихаешь и всё в компайл-тайм генерится.
G>Да и T4 в студии есть. По метаданным все что угодно сгенерить можно.
Я имел ввиду код, который BLToolkit генерирует во время работы программы.
Буду читать и разбираться. Но у меня на этот счёт другое мнение, почему бы просто всем методам DAL не принимать в качестве параметра DbTransaction. И я слабо представляю как можно реализовать Unit of Work, на основе только кэша. Наример если нам надо вызвать стору, получить результат и на его основе поменять несколько entity и вызвать ещё одну стору. Как тут обойтись только одним кэш-ем, непонятно. Но опять же это возможно из за моей неграмотности. Буду читать...
Народная мудрось
всем все никому ничего(с).
Re[11]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Aen Sidhe, Вы писали:
AS>Я имел ввиду код, который BLToolkit генерирует во время работы программы.
Есть утиль, которая генерит всё и сохраняет в либу. В рантайме BLToolkit проверяет её наличие, и если она есть, то юзает её и ничего не генерит... Именно про запихивание её в пост-билд была речь выше.
Мой выбор — BLToolkit + самопальный генератор. Эта связка умеет всё вышеперечисленное. Прозначная поддержка транзакций вроде не входит в либу, но на форуме есть простой класс, который добавляет эту фичу.
Здравствуйте, Tom, Вы писали:
A>>Кеш первого уровня NH, это часть Unit of Work.
Tom>Буду читать и разбираться. Но у меня на этот счёт другое мнение, почему бы просто всем методам DAL не принимать в качестве параметра DbTransaction.
Unit of Work, это бизнес-транзакция, т.е. она может включать в себя одну и более последовательный транзакций.
Unit of work модет делать следующее:
1) следить за тем, чтобы один и тот же объект не загружался из БД дважды в рамках одной Unit of Work
2) отслеживать изменения объектов, например, можно загрузить объекты из БД, часть из них поменять и Unit of Work сама определит какие объекты нужно обновить в БД
3) выполнять каскадные операции, например, при вставке или удалении графа объектов Unit of Work определит в какой последовательности нужно выполнить SQL операторы (DELETE, INSERT)
4) блокировки: пессимистические (SELECT FOR UPDATE), оптимичтические (на основе версий)
и пр.
1), 2), 3), 4) есть в NHibernate
2), 3) есть в Linq2SQL
Tom>И я слабо представляю как можно реализовать Unit of Work, на основе только кэша. Наример если нам надо вызвать стору, получить результат и на его основе поменять несколько entity и вызвать ещё одну стору. Как тут обойтись только одним кэш-ем, непонятно. Но опять же это возможно из за моей неграмотности. Буду читать...
Здравствуйте, Tom, Вы писали:
Tom>Да, абсолютно согласен, ещё я хочу отмести тех кто не позволяет гибко управлять генерацией C#/SQL. И тех у кого нет будущего. Тоесть Linq2Sql/EF тоже похоже уходят. По крайней мере Linq2Sql на 90% отметается
Не позволяют управлять генерацией? Или нет будущего?
Сам ни тем ни другим не пользовался — поэтому вопрос.
Dog>Самый большой плюс тулкита, как для меня, это то, что его просто и приятно допиливать руками
А нам оно надо? Мы бы с радостью платили за ком. продукт, который бы допиливали за наши деньги.
Здравствуйте, achmed, Вы писали:
A>Здравствуйте, Tom, Вы писали:
A>>>Кеш первого уровня NH, это часть Unit of Work.
Tom>>Буду читать и разбираться. Но у меня на этот счёт другое мнение, почему бы просто всем методам DAL не принимать в качестве параметра DbTransaction.
A>Unit of Work, это бизнес-транзакция, т.е. она может включать в себя одну и более последовательный транзакций.
A>Unit of work модет делать следующее:
A>1) следить за тем, чтобы один и тот же объект не загружался из БД дважды в рамках одной Unit of Work A>2) отслеживать изменения объектов, например, можно загрузить объекты из БД, часть из них поменять и Unit of Work сама определит какие объекты нужно обновить в БД A>3) выполнять каскадные операции, например, при вставке или удалении графа объектов Unit of Work определит в какой последовательности нужно выполнить SQL операторы (DELETE, INSERT) A>4) блокировки: пессимистические (SELECT FOR UPDATE), оптимичтические (на основе версий) A>и пр.
A>1), 2), 3), 4) есть в NHibernate A>2), 3) есть в Linq2SQL
не, я всё понимаю, но как в том же NHibernate-е в рамках одной транзакции, выполнить скажем сохранение обьекта в БД, и вызвать стору. По интерфейсу и описанию Unit of work я этого не понял.
не забудьте поделиться результатами
Если нам не помогут, то мы тоже никого не пощадим.
