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

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

Tom>>Да, абсолютно согласен, ещё я хочу отмести тех кто не позволяет гибко управлять генерацией C#/SQL. И тех у кого нет будущего. Тоесть Linq2Sql/EF тоже похоже уходят. По крайней мере Linq2Sql на 90% отметается

S>Не позволяют управлять генерацией? Или нет будущего?
S>Сам ни тем ни другим не пользовался — поэтому вопрос.

И то и то

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

Tom>не, я всё понимаю, но как в том же NHibernate-е в рамках одной транзакции, выполнить скажем сохранение обьекта в БД, и вызвать стору. По интерфейсу и описанию Unit of work я этого не понял.

Процедуры поддерживаются Native как и Native SQL.
Using NHibernate With Stored Procedures

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

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

Tom>>не, я всё понимаю, но как в том же NHibernate-е в рамках одной транзакции, выполнить скажем сохранение обьекта в БД, и вызвать стору. По интерфейсу и описанию Unit of work я этого не понял.

A>Процедуры поддерживаются Native как и Native SQL.
A>Using NHibernate With Stored Procedures

У меня не процедура для вставки чего то, а просто процедура которая чего то там делает. Например пересчитывает какие либо агрешаты. Вот как её вызов обьединить в NH в транзакцию? Как я понял из интерфейса Unit of Work, зарегистрировать можно только обьекты изменённые.

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

Tom>У меня не процедура для вставки чего то, а просто процедура которая чего то там делает. Например пересчитывает какие либо агрешаты. Вот как её вызов обьединить в NH в транзакцию? Как я понял из интерфейса Unit of Work, зарегистрировать можно только обьекты изменённые.

Так

ISession session = ...
...
var tx = session.BeginTransaction(level);
try
{
..
// сохраняем entity
session.Save(order);
// вызываем процедуру; перед вызовом NH сбросит в БД все изменения, сделанные в сессии
var result = session.GetNamedQuery("recalc_data").List<int>();
...
tx.Commit();
}
catch(Exception ex)
{
tx.Rollback();
throw;
}

в hbm

    <sql-query name="recalc_data">
        <return-scalar column="result" type="int"/>
        exec recalc_data
    </sql-query>

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

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

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

Tom>>>не, я всё понимаю, но как в том же NHibernate-е в рамках одной транзакции, выполнить скажем сохранение обьекта в БД, и вызвать стору. По интерфейсу и описанию Unit of work я этого не понял.

A>>Процедуры поддерживаются Native как и Native SQL.
A>>Using NHibernate With Stored Procedures

Tom>У меня не процедура для вставки чего то, а просто процедура которая чего то там делает. Например пересчитывает какие либо агрешаты. Вот как её вызов обьединить в NH в транзакцию? Как я понял из интерфейса Unit of Work, зарегистрировать можно только обьекты изменённые.

Никакой unit-of-work не может контроллировать данные, изменные не через этот Unit-of-work (например процедура на сервере или просто другой контекст).

Dog>>Самый большой плюс тулкита, как для меня, это то, что его просто и приятно допиливать руками
Tom>А нам оно надо? Мы бы с радостью платили за ком. продукт, который бы допиливали за наши деньги.
Что-то мне подсказывает, что вы не одни такие

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

Tom>А нам оно надо? Мы бы с радостью платили за ком. продукт, который бы допиливали за наши деньги.

Дык заплатите любому из мейнтенеров — и всё будет Вам же всё равно, кому платить — лишь бы результат был, не так ли?

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

Dog>>Самый большой плюс тулкита, как для меня, это то, что его просто и приятно допиливать руками
Tom>А нам оно надо? Мы бы с радостью платили за ком. продукт, который бы допиливали за наши деньги.

Дык, в чём проблема, за ценой не постоите?

Если серьёзно, то мне пока ещё ни разу не встречался более менее серьёзный проект, где бы не понадобилось что-то подкрутить руками. Если продукт этого не позволяет, то вместо подкрутов начинаются выверты. Можешь сразу заводить блокнотик и фиксировать в нём все извратсва, через которые вам придётся пройти. Через годик нам расскажешь

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

FD>>Я бы в этом случае использовал функции типа table-valued вместо хранимых процедур. Для них тип resultset известен.
Tom>В чём приймущестово, можно пояснить, я чессно говоря просто не вкурсе что это такое.

В Transact SQL можно создавать функции, возвращающие таблицу, типа этой:

CREATE FUNCTION dbo.Persons(@search nvarchar(100))
RETURNS table
AS
RETURN (select Person_Id,
               First_Name,
               Surname
         from Person 
         where Surname like @search)
GO

Это пример inline-функции. Есть еще более сложный вариант, когда в теле функции определяется временная таблица, которую можно заполнять, изменять и т.д. и которая в конце концов возвращается оператором return.

Такую функцию можно использовать, например, так:

select *
  from dbo.Persons('A%')

Информацию о столбцах результа можно получить на основе системных представлений INFORMATION_SCHEMA.ROUTINE_COLUMNS и INFORMATION_SCHEMA.ROUTINES. На основании этого OR-mapper может сгенерировать Entity, соответствующий структуре результата.

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

Однако я не знаю, какие OR-mapper'ы могут это делать. LLBLGen, например, табличные функции не распознает.

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

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

FD>>>Я бы в этом случае использовал функции типа table-valued вместо хранимых процедур. Для них тип resultset известен.
Tom>>В чём приймущестово, можно пояснить, я чессно говоря просто не вкурсе что это такое.

FD>В Transact SQL можно создавать функции, возвращающие таблицу, типа этой:

На функции накладывается ограничение: отсутсвтвие без побочных эффектов,
т.е. функция не должна менять состояние БД и при одних и тех же параметрах
возвращать одни и те же значения.

http://msdn.microsoft.com/en-us/library/aa258261(SQL.80).aspx

Это довольно сильное ограничение.

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

A>Здравствуйте, Flying Dutchman, Вы писали:

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

FD>>>>Я бы в этом случае использовал функции типа table-valued вместо хранимых процедур. Для них тип resultset известен.
Tom>>>В чём приймущестово, можно пояснить, я чессно говоря просто не вкурсе что это такое.

FD>>В Transact SQL можно создавать функции, возвращающие таблицу, типа этой:

A>На функции накладывается ограничение: отсутсвтвие без побочных эффектов,
A>т.е. функция не должна менять состояние БД и при одних и тех же параметрах
A>возвращать одни и те же значения.

A>http://msdn.microsoft.com/en-us/library/aa258261(SQL.80).aspx

A>Это довольно сильное ограничение.

Все правильно. Однако мы сравниваем функции и хранимые процедуры, возвращающе dataset. Довольно нелогично создавать такую хранимую процедуру с побочными эффектами. Все равно что иметь побочный эффект в select.

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

Прочитал всю тему, интересно, то-же как раз начал проект, использую Linq to SQL, но только из-за sqlmetal утилиты, которая генерит нужные мне классы из БД. Писать 100 классов от руки, и всё это подерживать слишком муторно.
Если бы для BLToolkit была бы такая же тулза да еще с разными фильтрами то сразу бы перешел на него, а так пока только Linq.

Может уже кто создал такую?

Другие библиотеки как-то не очень охота изучать

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

FD>Все правильно. Однако мы сравниваем функции и хранимые процедуры, возвращающе dataset. Довольно нелогично создавать такую хранимую процедуру с побочными эффектами.
Что в этом нелогичного?
FD>Все равно что иметь побочный эффект в select.
Если процедура возвращает resultset этот вовсе не значит что она обязана только читать.

IT>Если серьёзно, то мне пока ещё ни разу не встречался более менее серьёзный проект, где бы не понадобилось что-то подкрутить руками. Если продукт этого не позволяет, то вместо подкрутов начинаются выверты. Можешь сразу заводить блокнотик и фиксировать в нём все извратсва, через которые вам придётся пройти. Через годик нам расскажешь
Именно по этому я хочу что бы генерилка была сильно сильно конфигурируемая. Причём как C# так и SQL.
А если серьёзно, то я пока не совсем понимаю для чего может понадобится BLToolkit (кстате, никогда не понимал причём тут BL, когда это фактически DAL, разве что моднее ) если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними.

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

IT>>Если серьёзно, то мне пока ещё ни разу не встречался более менее серьёзный проект, где бы не понадобилось что-то подкрутить руками. Если продукт этого не позволяет, то вместо подкрутов начинаются выверты. Можешь сразу заводить блокнотик и фиксировать в нём все извратсва, через которые вам придётся пройти. Через годик нам расскажешь
Tom>Именно по этому я хочу что бы генерилка была сильно сильно конфигурируемая. Причём как C# так и SQL.

Вот, особенно про генерилки будет интересно. Как ты её будешь сильно конфигурировать и не окажется ли в конце концов, что сильнее конфигурилки, чем написание кода ручками нет

Tom>А если серьёзно, то я пока не совсем понимаю для чего может понадобится BLToolkit (кстате, никогда не понимал причём тут BL, когда это фактически DAL, разве что моднее )

Это не только поддержка DAL, это поддержка DAL в том числе. Это во-первых. Во-вторых, ты думаешь бизнес логика заканчивается одноимённым слоем? Это не так. WHERE clause, GROUP BY, HAVING — это всё тоже логика и к тому же самая что ни на есть бизнес.

Tom>если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними.

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

IT>Вот, особенно про генерилки будет интересно. Как ты её будешь сильно конфигурировать и не окажется ли в конце концов, что сильнее конфигурилки, чем написание кода ручками нет
Код ручками — это мы проходили в С++, от него не только крысы дохнут но и я могу окочуриться. Сотни руками написанных accessor-ов. Прикинь как нам было сладко когда надо было что то порефакторить.
На самом деле сами были виноваты, ведь сгенерить код можно было и на С++, но факт в том, что руками большую часть DAL-а писать это утопия.

IT>Это не только поддержка DAL, это поддержка DAL в том числе. Это во-первых. Во-вторых, ты думаешь бизнес логика заканчивается одноимённым слоем?
Ну ладно ладно, признайся что для пущей серьёзности?

IT>Это не так. WHERE clause, GROUP BY, HAVING — это всё тоже логика и к тому же самая что ни на есть бизнес.
А я даже и спорить не хочу, и даже если попросите, сильно. Я полностью согласен

Tom>>если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними.
IT>Что ты хочешь ей генерировать, CRUDL? Так это без проблем делается и без генерации всякого мусора.
Я в принципе писал что хочу, но, как минимум:
1. CRUD (с различными вариантами блокировок)
2. Обёртки вокруг стор
3. Обёртки вокруг обычных запросов, при этом идеально будет если запрос каждый можно будет держать в отдельном SQL файле. Для того, что бы полностью GDR использовать.

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

IT>>Вот, особенно про генерилки будет интересно. Как ты её будешь сильно конфигурировать и не окажется ли в конце концов, что сильнее конфигурилки, чем написание кода ручками нет
Tom>Код ручками — это мы проходили в С++, от него не только крысы дохнут но и я могу окочуриться. Сотни руками написанных accessor-ов. Прикинь как нам было сладко когда надо было что то порефакторить.

Думаешь слаще будет рефакторить сгенерированный код? Легче всего рефакторить код, которого нет.

Tom>На самом деле сами были виноваты, ведь сгенерить код можно было и на С++, но факт в том, что руками большую часть DAL-а писать это утопия.

Этого делать никто не предлагает. Писать DAL уже давно не модно.

Tom>>>если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними.
IT>>Что ты хочешь ей генерировать, CRUDL? Так это без проблем делается и без генерации всякого мусора.
Tom>Я в принципе писал что хочу, но, как минимум:
Tom>1. CRUD (с различными вариантами блокировок)
Tom>2. Обёртки вокруг стор
Tom>3. Обёртки вокруг обычных запросов, при этом идеально будет если запрос каждый можно будет держать в отдельном SQL файле. Для того, что бы полностью GDR использовать.

Всё это делается на булките с пол пинка без всяких генераций. Подробности здесь.

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

A>Здравствуйте, Flying Dutchman, Вы писали:


A>Если процедура возвращает resultset этот вовсе не значит что она обязана только читать.

Не обязана. Но будет лучше, если она будет либо возвращать recordset, либо изменять что-либо в базе данных.

Если же мы сравниваем хранимые процедуры, только возвращающие recordset, с table-valued функциями, то разницы почти никакой. Единственное важное отличие в том, что результат, возвращаемый хранимой процедурой, может быть уже отсортирован.

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

FD>Не обязана. Но будет лучше, если она будет либо возвращать recordset, либо изменять что-либо в базе данных.

FD>Если же мы сравниваем хранимые процедуры, только возвращающие recordset, с table-valued функциями, то разницы почти никакой. Единственное важное отличие в том, что результат, возвращаемый хранимой процедурой, может быть уже отсортирован.

Можно придумать тысячу причин чтобы ограничивать себя использованием функций, только на практике выйдет боком.

Пример из жизни, процедура, выполняющая сложный поиск.
Сначала в ней простой SELECT, потом появляется заполнение кешей, потом сохранрение промежуточного результата для для сужающего параметрического поиска, потом логирование критериев поиска и хрен знает что еще добавится. (Ах да, отладочная печать, ее тоже нельзя использовать в функциях.)
Только не мало писать, что код надо было разнести по разным процедурам и вызывать из последовательно. Нельзя, потому процедура это контракт между между приложением и БД.

IT>Думаешь слаще будет рефакторить сгенерированный код? Легче всего рефакторить код, которого нет.
Я сгенерированный код не предпологаю рефакторить. План такой, если что то не устраивает в нём — поменять/поправить шаблоны генерации и перегенерить.
Если быть точнее, я хочу всегад при компиляции генерить DAL. Что бы он всегда был up to date.
По поводу кода которого нет — это фикция. Код всегда есть. А в случаях когда его нет ЯВНО — особенна приятна отладка

Tom>>На самом деле сами были виноваты, ведь сгенерить код можно было и на С++, но факт в том, что руками большую часть DAL-а писать это утопия.
IT>Этого делать никто не предлагает. Писать DAL уже давно не модно.
Вот и я о том же, что не модно...

Tom>>>>если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними.
IT>>>Что ты хочешь ей генерировать, CRUDL? Так это без проблем делается и без генерации всякого мусора.
Tom>>Я в принципе писал что хочу, но, как минимум:
Tom>>1. CRUD (с различными вариантами блокировок)
Tom>>2. Обёртки вокруг стор
Tom>>3. Обёртки вокруг обычных запросов, при этом идеально будет если запрос каждый можно будет держать в отдельном SQL файле. Для того, что бы полностью GDR использовать.
IT>Всё это делается на булките с пол пинка без всяких генераций. Подробности здесь.
Спасибо, читаю.