Здравствуйте, baranovda, Вы писали:
B>Здравствуйте, Tom, Вы писали:
Tom>>Рефакторим и переписываем на .NET большой проект. Встаёт дилема/проблема выбора framework-а для работы с данными.
B>У вас не возникало желания снять с себя весь этот геморрой с бизнес- и сервис-слоями и транспортом, и взять какую-нить ERP-систему?
И получить геморрой в виде ERP-системы %) (Я внедрял несколько, так что знаком не понаслышке)
Как я понял нужен просто data mapper и генерилка POCO и маппингов. Как маппер можно использовать iBatis, BLToolkit даже NHibernate не заставляет тебя использовать больше его возможностей чем требуется. Осталось выбрать генерилку маппингов и сущностей по схеме базы. MyGeneration, CodeSmith, ddl2hbm.
Рефакторим и переписываем на .NET большой проект. Встаёт дилема/проблема выбора framework-а для работы с данными.
Основная концепция — это разумная автоматизация. Я не хочу делать всё руками, но и не хочу отказываться от стор и написания TSQL кода.
Я для себя набросал некоторые требования к нашему DAL Framework. Может многоуважаемый ALL посоветует какое то готовое решение.
Ну и просто мысли и замечания — велкам. Ответы желательно максимально конкретизировать и избежать обсуждения "сферического коня в вакууме".
DAL Framework должен:
1. Позволять генерировать C# wrapper-ы для
1.1. Вызова хранимых процедур, при этом если хранимая процедура возвращает resultset, то entity класс так же должен быть сгенерирован
1.2. Таблиц/View (CRUD), при этом очень желательно что бы при помощи сгенерированного класса можно было бы обновить как одно или несколько полей, так и все поля
1.3. Custom запросов (не хранимых процедур).
Например мы хотим сделать некоторый select, но нехотим делать хранимую процедуру, при этом мы хотим, что бы entity сгенерировалась DAL Framework-ом автоматически, по полям выборки
1.3. Сгенерированный DAL должен нормально поддерживать транзакционность
Тоесть, должна быть возможность например обновить несколько таблиц и вызвать стору в одной транзакции без использования TransactionScope
Не хочется для одной транзакции использовать несколько соединений с БД, например из за увеличения риска дедлоков
1.4. Сгенерированные entity классы должны легко сериализовываться в XML
1.5. Сгенерированные entity классы должны легко передаваться по WCF
1.6. Сгенерированные entity классы должны быть disconnected от базы
1.7. Чем проще будут сгенерированные entity классы — тем лучше. Естественно, что POCO буде идеалом
1.8. Естественно все сгенерированные классы должны быть Partial
1.9. Гибкое управление (возможность контролировать) сгенерированным C# кодом будет большим плюсом
1.10 Гибкое управление (возможность контролировать) сгенерированным TSQL кодом будет большим плюсом
2. Должна быть возможность генерировать (или обновлять уже существующий) DAL по базе во время билда, а не только из студии или какой либо утилиты
Нужно что бы сгенерированный DAL всегда был бы up to date и иметь compile time проверки
3. В идеале должен быть хорошо поддерживаемым комерческим продуктом, ещё лучше если будут доступны исходники
4. В идеале должен быть заточен, или очень хорошо понимать MS SQL 2005/2008
DAL Framework НЕ должен:
1. Быть полноценным ORM с поддержкой связей, коллекций, многоуровневых внутренних кэшэй и прочей "тяжеловесной" ерунды с которой в будущем придётся бороться
2. Не должен заменять SQL своим языком, или уж если и заменяет то это должна быть полная/полноценная поддержка TSQL 2005/TSQL 2008
Писать велосипед не предлагать
Во флэйм не пускаться
Спасибо!
Народная мудрось
всем все никому ничего(с).
Re[10]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Tom, Вы писали:
Dog>>Самый большой плюс тулкита, как для меня, это то, что его просто и приятно допиливать руками Tom>А нам оно надо? Мы бы с радостью платили за ком. продукт, который бы допиливали за наши деньги.
Дык, в чём проблема, за ценой не постоите?
Если серьёзно, то мне пока ещё ни разу не встречался более менее серьёзный проект, где бы не понадобилось что-то подкрутить руками. Если продукт этого не позволяет, то вместо подкрутов начинаются выверты. Можешь сразу заводить блокнотик и фиксировать в нём все извратсва, через которые вам придётся пройти. Через годик нам расскажешь
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, achmed.
S>Согласен. Использовать TVF только из-за того, что stored procedures могут вернуть несколько резалтсетов выглядит странно. Если интересно как студия получает схему резалтсета — создайте dataset, запустите визард, что генерит таблицы по выбранным процедурам (add new table... и поехали) и мониторьте sql profiler'ом. Там нет абсолютно никакой магии.
Скорее всего для этого используется вызов хранимой процедуры в таком виде:
set fmtonly on
exec my_proc
set fmtonly off
При этом возвращается только описание resultset (без данных).
Я бы отмел те фреймворки которые обязывают завязывать классы данных на себя, наследованием от их объекта например. XPO, CSLA.Net, Net tiers(?). Объекты которые подобно Мюнхгаузену вытаскивают себя из базы и сохраняют обратно (ActiveRecord) это антипаттерн, который допустим лишь для быстрой разработки простых приложений. Кстати, почему в списке нет iBatis? Довольно простой и прозрачный для программиста маппер.
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[12]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, 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;
}
Здравствуйте, 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, например, табличные функции не распознает.
Здравствуйте, Tom, Вы писали:
Tom>Рефакторим и переписываем на .NET большой проект. Встаёт дилема/проблема выбора framework-а для работы с данными. Tom>Основная концепция — это разумная автоматизация. Я не хочу делать всё руками, но и не хочу отказываться от стор и написания TSQL кода. Tom>Я для себя набросал некоторые требования к нашему DAL Framework. Может многоуважаемый ALL посоветует какое то готовое решение. Tom>Ну и просто мысли и замечания — велкам. Ответы желательно максимально конкретизировать и избежать обсуждения "сферического коня в вакууме".
Для ескольких последник проектов использовал LLBLGen Pro.
Tom>DAL Framework должен: Tom>1. Позволять генерировать C# wrapper-ы для Tom>1.1. Вызова хранимых процедур, при этом если хранимая процедура возвращает resultset, то entity класс так же должен быть сгенерирован
Генерируются wrapper-ы для хранимых процедур. Автоматически определяется, какие процедуры возвращают resultset, какие нет. Для процедур, возвращающих resultset,
результат возвращается в виде DataSet. Entity-класс для этих случаев не генерируется, так как это невозможно сделать в принципе.
Tom>1.2. Таблиц/View (CRUD), при этом очень желательно что бы при помощи сгенерированного класса можно было бы обновить как одно или несколько полей, так и все поля
Генерируются классы как для таблиц, так и для представлений.
Tom>1.3. Custom запросов (не хранимых процедур). Tom>Например мы хотим сделать некоторый select, но не хотим делать хранимую процедуру, при этом мы хотим, что бы entity сгенерировалась DAL Framework-ом автоматически, по полям выборки
Кажется, эта возможность есть и называется Typed View (точно не знаю).
Tom>1.3. Сгенерированный DAL должен нормально поддерживать транзакционность Tom>Тоесть, должна быть возможность например обновить несколько таблиц и вызвать стору в одной транзакции без использования TransactionScope
Да
Tom>Не хочется для одной транзакции использовать несколько соединений с БД, например из за увеличения риска дедлоков Tom>1.4. Сгенерированные entity классы должны легко сериализовываться в XML
Да
Tom>1.5. Сгенерированные entity классы должны легко передаваться по WCF
Точно не знаю, кажется, в последней версии это реализовано.
Tom>1.6. Сгенерированные entity классы должны быть disconnected от базы
Да.
Tom>1.7. Чем проще будут сгенерированные entity классы — тем лучше. Естественно, что POCO буде идеалом
Не знаю, что такое POCO. Можно генерировать классы в двух режимах:
1. Self-servicing — классы содержат данные + всю логику для их чтения из БД,
обработки и сохранения в БД.
2. Adapter — классы содержат только данные. Обработка данных осуществяется отдельными классами.
Tom>1.8. Естественно все сгенерированные классы должны быть Partial
Да
Tom>1.9. Гибкое управление (возможность контролировать) сгенерированным C# кодом будет большим плюсом
Можно создавать свои шаблоны для генерации C#-классов.
Tom>1.10 Гибкое управление (возможность контролировать) сгенерированным TSQL кодом будет большим плюсом
TSQL-код генерируется динамически в процессе работы. Насчет управления процессом его генерации точно не знаю.
Tom>2. Должна быть возможность генерировать (или обновлять уже существующий) DAL по базе во время билда, а не только из студии или какой либо утилиты.
Проект для DAL создается вручную при помощи программы-дизайнера. Впоследствии, при изменении структуры БД его можно обновлять либо вручную, либо про помощи утилиты Cli refresher, работающей из командной строки (я ей не пользовался).
Tom>Нужно что бы сгенерированный DAL всегда был бы up to date и иметь compile time проверки
Наверное, это можно реализовать при помощи cli refresher.
Tom>3. В идеале должен быть хорошо поддерживаемым комерческим продуктом, ещё лучше если будут доступны исходники
Да
Tom>4. В идеале должен быть заточен, или очень хорошо понимать MS SQL 2005/2008
Да
Tom>DAL Framework НЕ должен: Tom>1. Быть полноценным ORM с поддержкой связей, коллекций, многоуровневых внутренних кэшэй и прочей "тяжеловесной" ерунды с которой в будущем придётся бороться
Поддержка связей и коллекций присутствует.
Tom>2. Не должен заменять SQL своим языком, или уж если и заменяет то это должна быть полная/полноценная поддержка TSQL 2005/TSQL 2008
Своего языка нет. Структура генерируемых классов полностью определяется структурой БД.
Дополнительные возможности:
— Загрузка данных по умолчанию lazy, но можно гибко сконфигурировать, какие данные должны загружаться сразу.
— Возможность чтения графа объектов на один раз.
— Поддержка наследования сущностей в БД
— Настройка преобразования типов данных БД в типы данных C# и обратно (это важно в основном при работе с Oracle).
Здравствуйте, Tom, Вы писали:
Z>>Вобщем-то NHibernate получается довольно неплох, кроме того, что кеш первого уровня у него отключить проблематично (хотя я не могу придумать зачем, кроме экономии памяти). Tom>А нафик он нам нужен. Что у насм будет — это свой кэш на основе SqlDependency. При этом естественно что SqlDependency будет создаваться на список обьектов, а не на каждый обьект своя.
Мой выбор — BLToolkit + самопальный генератор. Эта связка умеет всё вышеперечисленное. Прозначная поддержка транзакций вроде не входит в либу, но на форуме есть простой класс, который добавляет эту фичу.
Здравствуйте, Tom, Вы писали:
IT>>Если серьёзно, то мне пока ещё ни разу не встречался более менее серьёзный проект, где бы не понадобилось что-то подкрутить руками. Если продукт этого не позволяет, то вместо подкрутов начинаются выверты. Можешь сразу заводить блокнотик и фиксировать в нём все извратсва, через которые вам придётся пройти. Через годик нам расскажешь Tom>Именно по этому я хочу что бы генерилка была сильно сильно конфигурируемая. Причём как C# так и SQL.
Вот, особенно про генерилки будет интересно. Как ты её будешь сильно конфигурировать и не окажется ли в конце концов, что сильнее конфигурилки, чем написание кода ручками нет
Tom>А если серьёзно, то я пока не совсем понимаю для чего может понадобится BLToolkit (кстате, никогда не понимал причём тут BL, когда это фактически DAL, разве что моднее )
Это не только поддержка DAL, это поддержка DAL в том числе. Это во-первых. Во-вторых, ты думаешь бизнес логика заканчивается одноимённым слоем? Это не так. WHERE clause, GROUP BY, HAVING — это всё тоже логика и к тому же самая что ни на есть бизнес.
Tom>если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними.
Что ты хочешь ей генерировать, CRUDL? Так это без проблем делается и без генерации всякого мусора.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Tom, Вы писали:
IT>>Думаешь слаще будет рефакторить сгенерированный код? Легче всего рефакторить код, которого нет. Tom>Я сгенерированный код не предпологаю рефакторить. План такой, если что то не устраивает в нём — поменять/поправить шаблоны генерации и перегенерить.
Это мы всё проходили. Работает это в разнах сценариях по разному. Например, так. За два часа до релиза находится проблема в сгенерированном коде, править генерилку некогда, поэтому изменения вносятся прямо в сгенерированный код. После релиза и шампанского про эту правку забывают. Другой сценарий, приходит новый человек на проект и начинает править сгенерированный код налево и направо. Через пару недель ему, конечно, надают по рукам, но за это время он понаделает столько, что переделывать хватит ещё на две недели.
Tom>Если быть точнее, я хочу всегад при компиляции генерить DAL. Что бы он всегда был up to date.
Ага, только не забудь про соурс контрол. Не забудь ему и студии объяснить, что каждый девелопер при каждой компиляции будет чекаутить по пол проекта, а потом эти пол проекта сабмитить.
Tom>По поводу кода которого нет — это фикция. Код всегда есть. А в случаях когда его нет ЯВНО — особенна приятна отладка
Зато отладка сгенерированного кода, который есть вдвойне приятна. Отлаживаешь, отлаживаешь, находишь проблему, а исправить не можешь. Хотя почему не можешь? Берешь и правишь, ведь про то, что это сгенерированный код можно забыть, не знать, нет времени на правку генератора.
В общем, ты тетрадочку всё-таки заведи. Весёлые воспоминания я тебе гарантирую
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Data Access Layer (EF/Linq2Sql and others)
IT>Это мы всё проходили. Работает это в разнах сценариях по разному. Например, так. За два часа до релиза находится проблема в сгенерированном коде, править генерилку некогда, поэтому изменения вносятся прямо в сгенерированный код. После релиза и шампанского про эту правку забывают. Другой сценарий, приходит новый человек на проект и начинает править сгенерированный код налево и направо. Через пару недель ему, конечно, надают по рукам, но за это время он понаделает столько, что переделывать хватит ещё на две недели.
Слушай, есть в проекте есть люди которые делают работу через ж@@пу, то тут ничего не спасёт В моём случае сгенерированные классы править будет просто невозможно. так как билд процесс будет устроен тауим образом, что при каждом билде всё будет генерироваться с нуля. По крайней мере на билд сервере. В общем эта проблема — не наш случай.
Tom>>Если быть точнее, я хочу всегад при компиляции генерить DAL. Что бы он всегда был up to date. IT>Ага, только не забудь про соурс контрол. Не забудь ему и студии объяснить, что каждый девелопер при каждой компиляции будет чекаутить по пол проекта, а потом эти пол проекта сабмитить.
Ничего не понимаю, с чего вдруг надо чекаутить пол проекта, и тем более пол проекта забирать. Сейчас например у нас много чего генерируется, спокойно, ничего не чекайтится вообще, и тем более не чекинится. Поясни о чём ты.
Tom>>По поводу кода которого нет — это фикция. Код всегда есть. А в случаях когда его нет ЯВНО — особенна приятна отладка
IT>Зато отладка сгенерированного кода, который есть вдвойне приятна. Отлаживаешь, отлаживаешь, находишь проблему, а исправить не можешь. Хотя почему не можешь? Берешь и правишь, ведь про то, что это сгенерированный код можно забыть, не знать, нет времени на правку генератора.
Вот об этом я и писал. Тул который генерирует код должен быть максимально флексибле. Этим меня не устраивает Sql Metal, я никак реально не могу изменить правила по которым она генерит код. Если у тебя нет возможности изменить генерацию — то конечно будут случаи когда придётся править сгенерированный код, что есть полжая ж@@па при сопровождении.
IT>В общем, ты тетрадочку всё-таки заведи. Весёлые воспоминания я тебе гарантирую
Да в общем я тут буду делиться наверное. Вот LLBLGenPro уже отвалился из списка кандидатов ((
PS:
По поводу генерации и BLToolKit, основная проблема с BLToolKit-ом в том, что нет генерилки и я не могу держать постоянно код up to date с базой. Например я описать какой то ad hoc запрос, думаю это возможно при помощи атрибутов. Реально у меня нет шансов провериро его выполнение в compile time. Ну и генерить entity капкой то другой тулзой для BLToolKit-а выглядит по меньшей мере странно. Вот допустим у нас есть 1000 стор, представь как это будет выглядеть, сгенерировать кучук таких классов, в потом ручками описать все вызовы в акцесорах (.
PPS:
Всё что можно сгенерировать автоматически — должно быть сгенерировать автоматически.
Здравствуйте, Holms, Вы писали:
H>Может уже кто создал такую?
Так сядь и напиши Для таблиц там вообще нечего делать — работы на час-полтора, с хранимками сложнее, но тоже решаемо. Зато будет тулза, которая удобна вам и делает именно то, что нужно вам, и именно так, как нужно вам...
Здравствуйте, Tom, Вы писали:
IT>>Потому что она генерирует императивный код, который можно изменить руками и сильно в этом преуспеть, а потом потерять все изменения даже этого не заметив. Tom>Игорь, мы не будем менять сгенерированный код, и даже в SCM его класть не будем
Это ты не будешь его никуда класть, а студия будет ещё как. Попробуй ради эксперимента.
IT>>1. Потенциальная (и главное непредсказуемая) возможность менять императив в сгенерированном коде. Tom>Как писал выше — отпадает. Руками абсолютно точно никто ничего менять не будет.
Заведи для этого отдельную тетрадку
IT>>2. Проблемы с соурс-контролом. Tom>Так и не понят какие.
Поэкспериментируй и поймёшь.
IT>>Что касается самого генератора, который ты пытаешься найти под себя, то его легче написать самому. На это ушло бы в три раза меньше времени, чем мы тут потраили на трёп и результат был бы такой, какой нужен именно тебе. Tom>Чукча постарел, обзавёлса жирком на бочках и уже давно не учавствует в велосипедных гонках. Да и есть у меня сомнения в том что оно можно быстро написать. Да и зачем если есть уже готовые решения.
А сомнений в том, что ты найдёшь не совсем то, что тебе нужно у тебя нет? Да и на настройку стандартного велосипеда у тебя уйдёт не меньше времени, чем на написание своего собственного.
Если нам не помогут, то мы тоже никого не пощадим.
Спасибо!
FD>Генерируются wrapper-ы для хранимых процедур. Автоматически определяется, какие процедуры возвращают resultset, какие нет. Для процедур, возвращающих resultset, FD>результат возвращается в виде DataSet. Entity-класс для этих случаев не генерируется, так как это невозможно сделать в принципе.
Не то что бы невозможно, но иногда невозможно или нетривиально. Linq2Sql генерит энтити по умолчанию и без особых проблем.
B>У вас не возникало желания снять с себя весь этот геморрой с бизнес- и сервис-слоями и транспортом, и взять какую-нить ERP-систему?
Этот вариант не рассматривается в принципе
Z>Как я понял нужен просто data mapper и генерилка POCO и маппингов. Как маппер можно использовать iBatis, BLToolkit даже NHibernate не заставляет тебя использовать больше его возможностей чем требуется. Осталось выбрать генерилку маппингов и сущностей по схеме базы. MyGeneration, CodeSmith, ddl2hbm.
Спасибо, я как то сразу и не догадался что в принципе это разные вещи. Однако лучше конечно интегрированное решение.
Здравствуйте, Tom, Вы писали:
Tom>Спасибо, я как то сразу и не догадался что в принципе это разные вещи. Однако лучше конечно интегрированное решение.
Скорее всего все интегрированные решения будут накладывать ограничения несовместимые с требованиями. Как минимум генерить они будут только под свой ORM, а все коммерческие ORM жутко навороченны на мой взгляд. Всетаки с такими четкими критериями придется много тюнить, а интегрированные решения с очень большой вероятностью не позволят это делать.
Z>Скорее всего все интегрированные решения будут накладывать ограничения несовместимые с требованиями. Как минимум генерить они будут только под свой ORM, а все коммерческие ORM жутко навороченны на мой взгляд. Всетаки с такими четкими критериями придется много тюнить, а интегрированные решения с очень большой вероятностью не позволят это делать.
Вот вот, по этому в идеале то что генерится — должно настраиваться. Шаблонами
Здравствуйте, Tom, Вы писали:
Tom>Спасибо!
FD>>Генерируются wrapper-ы для хранимых процедур. Автоматически определяется, какие процедуры возвращают resultset, какие нет. Для процедур, возвращающих resultset, FD>>результат возвращается в виде DataSet. Entity-класс для этих случаев не генерируется, так как это невозможно сделать в принципе. Tom>Не то что бы невозможно, но иногда невозможно или нетривиально. Linq2Sql генерит энтити по умолчанию и без особых проблем.
Мы говорим об SQL Server ? В этом случае сгенерировать Entity-класс для результата храномой процедуры невозможно, так как структура возвращаемого хранимой процедурой resultset определяется динамически в процессе вызова процедуры. И resultset может быть разным в зависимости от логики процедуры. Например, в приведенном примере хранимая процедура может возвращать результат одного из двух типов:
create procedure person_or_company(@flag bit)
as
begin
if @flag = 1
select * from Person
else
select * from Company
end
Не говоря уже о таком примере:
create procedure proc_with_different_result_sets(@select nvarchar(4000))
as
begin
exec dbo.sp_executesql @select
end
Или, может быть, ты имеешь в виду результат, возвращаемый функцией типа table-valued ? В таком случае структура результата известна и Entity-класс сгенерировать можно.
Здравствуйте, Flying Dutchman, Вы писали:
FD>>>Генерируются wrapper-ы для хранимых процедур. Автоматически определяется, какие процедуры возвращают resultset, какие нет. Для процедур, возвращающих resultset, FD>>>результат возвращается в виде DataSet. Entity-класс для этих случаев не генерируется, так как это невозможно сделать в принципе. Tom>>Не то что бы невозможно, но иногда невозможно или нетривиально. Linq2Sql генерит энтити по умолчанию и без особых проблем.
FD>Мы говорим об SQL Server ? В этом случае сгенерировать Entity-класс для результата храномой процедуры невозможно, так как структура возвращаемого хранимой процедурой resultset определяется динамически в процессе вызова процедуры.
Можно генерировать для тех процедур, у которых структура resultset статична.
Например, Codesmith чтобы определить resultset процедуры запускает процедуру
с параметрами по умолчанию, нам этого хватало в 90% случаев.
Здравствуйте, achmed, Вы писали:
A>Здравствуйте, Flying Dutchman, Вы писали:
FD>>Мы говорим об SQL Server ? В этом случае сгенерировать Entity-класс для результата храномой процедуры невозможно, так как структура возвращаемого хранимой процедурой resultset определяется динамически в процессе вызова процедуры.
A>Можно генерировать для тех процедур, у которых структура resultset статична. A>Например, Codesmith чтобы определить resultset процедуры запускает процедуру A>с параметрами по умолчанию, нам этого хватало в 90% случаев.
Я бы в этом случае использовал функции типа table-valued вместо хранимых процедур. Для них тип resultset известен.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Tom, Вы писали:
Z>Я бы отмел те фреймворки которые обязывают завязывать классы данных на себя, наследованием от их объекта например. XPO, CSLA.Net, Net tiers(?). Объекты которые подобно Мюнхгаузену вытаскивают себя из базы и сохраняют обратно (ActiveRecord) это антипаттерн, который допустим лишь для быстрой разработки простых приложений. Кстати, почему в списке нет iBatis? Довольно простой и прозрачный для программиста маппер.
Да, абсолютно согласен, ещё я хочу отмести тех кто не позволяет гибко управлять генерацией C#/SQL. И тех у кого нет будущего. Тоесть Linq2Sql/EF тоже похоже уходят. По крайней мере Linq2Sql на 90% отметается
FD>Я бы в этом случае использовал функции типа table-valued вместо хранимых процедур. Для них тип resultset известен.
В чём приймущестово, можно пояснить, я чессно говоря просто не вкурсе что это такое.
Здравствуйте, 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 сессия может быть полезной, например, для вставки большого объема данных.
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 проверяет её наличие, и если она есть, то юзает её и ничего не генерит... Именно про запихивание её в пост-билд была речь выше.
Здравствуйте, 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 я этого не понял.
Здравствуйте, Severn, Вы писали:
S>Здравствуйте, Tom, Вы писали:
Tom>>Да, абсолютно согласен, ещё я хочу отмести тех кто не позволяет гибко управлять генерацией C#/SQL. И тех у кого нет будущего. Тоесть Linq2Sql/EF тоже похоже уходят. По крайней мере Linq2Sql на 90% отметается
S>Не позволяют управлять генерацией? Или нет будущего? S>Сам ни тем ни другим не пользовался — поэтому вопрос.
И то и то
Народная мудрось
всем все никому ничего(с).
Re[10]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Tom, Вы писали:
Tom>не, я всё понимаю, но как в том же NHibernate-е в рамках одной транзакции, выполнить скажем сохранение обьекта в БД, и вызвать стору. По интерфейсу и описанию Unit of work я этого не понял.
Здравствуйте, achmed, Вы писали:
A>Здравствуйте, Tom, Вы писали:
Tom>>не, я всё понимаю, но как в том же NHibernate-е в рамках одной транзакции, выполнить скажем сохранение обьекта в БД, и вызвать стору. По интерфейсу и описанию Unit of work я этого не понял.
A>Процедуры поддерживаются Native как и Native SQL. A>Using NHibernate With Stored Procedures
У меня не процедура для вставки чего то, а просто процедура которая чего то там делает. Например пересчитывает какие либо агрешаты. Вот как её вызов обьединить в NH в транзакцию? Как я понял из интерфейса Unit of Work, зарегистрировать можно только обьекты изменённые.
Народная мудрось
всем все никому ничего(с).
Re[12]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, 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 (например процедура на сервере или просто другой контекст).
Re[10]: Data Access Layer (EF/Linq2Sql and others)
Dog>>Самый большой плюс тулкита, как для меня, это то, что его просто и приятно допиливать руками Tom>А нам оно надо? Мы бы с радостью платили за ком. продукт, который бы допиливали за наши деньги.
Что-то мне подсказывает, что вы не одни такие
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[10]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Flying Dutchman, Вы писали:
FD>Здравствуйте, Tom, Вы писали:
FD>>>Я бы в этом случае использовал функции типа table-valued вместо хранимых процедур. Для них тип resultset известен. Tom>>В чём приймущестово, можно пояснить, я чессно говоря просто не вкурсе что это такое.
FD>В Transact SQL можно создавать функции, возвращающие таблицу, типа этой:
На функции накладывается ограничение: отсутсвтвие без побочных эффектов,
т.е. функция не должна менять состояние БД и при одних и тех же параметрах
возвращать одни и те же значения.
Здравствуйте, 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.
Прочитал всю тему, интересно, то-же как раз начал проект, использую Linq to SQL, но только из-за sqlmetal утилиты, которая генерит нужные мне классы из БД. Писать 100 классов от руки, и всё это подерживать слишком муторно.
Если бы для BLToolkit была бы такая же тулза да еще с разными фильтрами то сразу бы перешел на него, а так пока только Linq.
Может уже кто создал такую?
Другие библиотеки как-то не очень охота изучать
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
The life is relative and reversible.
Re[10]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Flying Dutchman, Вы писали:
FD>Все правильно. Однако мы сравниваем функции и хранимые процедуры, возвращающе dataset. Довольно нелогично создавать такую хранимую процедуру с побочными эффектами.
Что в этом нелогичного? FD>Все равно что иметь побочный эффект в select.
Если процедура возвращает resultset этот вовсе не значит что она обязана только читать.
Re[11]: Data Access Layer (EF/Linq2Sql and others)
IT>Если серьёзно, то мне пока ещё ни разу не встречался более менее серьёзный проект, где бы не понадобилось что-то подкрутить руками. Если продукт этого не позволяет, то вместо подкрутов начинаются выверты. Можешь сразу заводить блокнотик и фиксировать в нём все извратсва, через которые вам придётся пройти. Через годик нам расскажешь
Именно по этому я хочу что бы генерилка была сильно сильно конфигурируемая. Причём как C# так и SQL.
А если серьёзно, то я пока не совсем понимаю для чего может понадобится BLToolkit (кстате, никогда не понимал причём тут BL, когда это фактически DAL, разве что моднее ) если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними.
Народная мудрось
всем все никому ничего(с).
Re[13]: Data Access Layer (EF/Linq2Sql and others)
IT>Вот, особенно про генерилки будет интересно. Как ты её будешь сильно конфигурировать и не окажется ли в конце концов, что сильнее конфигурилки, чем написание кода ручками нет
Код ручками — это мы проходили в С++, от него не только крысы дохнут но и я могу окочуриться. Сотни руками написанных accessor-ов. Прикинь как нам было сладко когда надо было что то порефакторить.
На самом деле сами были виноваты, ведь сгенерить код можно было и на С++, но факт в том, что руками большую часть DAL-а писать это утопия.
IT>Это не только поддержка DAL, это поддержка DAL в том числе. Это во-первых. Во-вторых, ты думаешь бизнес логика заканчивается одноимённым слоем?
Ну ладно ладно, признайся что для пущей серьёзности?
IT>Это не так. WHERE clause, GROUP BY, HAVING — это всё тоже логика и к тому же самая что ни на есть бизнес.
А я даже и спорить не хочу, и даже если попросите, сильно. Я полностью согласен
Tom>>если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними. IT>Что ты хочешь ей генерировать, CRUDL? Так это без проблем делается и без генерации всякого мусора.
Я в принципе писал что хочу, но, как минимум:
1. CRUD (с различными вариантами блокировок)
2. Обёртки вокруг стор
3. Обёртки вокруг обычных запросов, при этом идеально будет если запрос каждый можно будет держать в отдельном SQL файле. Для того, что бы полностью GDR использовать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[14]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Tom, Вы писали:
IT>>Вот, особенно про генерилки будет интересно. Как ты её будешь сильно конфигурировать и не окажется ли в конце концов, что сильнее конфигурилки, чем написание кода ручками нет Tom>Код ручками — это мы проходили в С++, от него не только крысы дохнут но и я могу окочуриться. Сотни руками написанных accessor-ов. Прикинь как нам было сладко когда надо было что то порефакторить.
Думаешь слаще будет рефакторить сгенерированный код? Легче всего рефакторить код, которого нет.
Tom>На самом деле сами были виноваты, ведь сгенерить код можно было и на С++, но факт в том, что руками большую часть DAL-а писать это утопия.
Этого делать никто не предлагает. Писать DAL уже давно не модно.
Tom>>>если у нас есть генерилка которая сгенерит не только entity но и код для работы с ними. IT>>Что ты хочешь ей генерировать, CRUDL? Так это без проблем делается и без генерации всякого мусора. Tom>Я в принципе писал что хочу, но, как минимум: Tom>1. CRUD (с различными вариантами блокировок) Tom>2. Обёртки вокруг стор Tom>3. Обёртки вокруг обычных запросов, при этом идеально будет если запрос каждый можно будет держать в отдельном SQL файле. Для того, что бы полностью GDR использовать.
Всё это делается на булките с пол пинка без всяких генераций. Подробности здесь.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, achmed, Вы писали:
A>Здравствуйте, Flying Dutchman, Вы писали:
A>Если процедура возвращает resultset этот вовсе не значит что она обязана только читать.
Не обязана. Но будет лучше, если она будет либо возвращать recordset, либо изменять что-либо в базе данных.
Если же мы сравниваем хранимые процедуры, только возвращающие recordset, с table-valued функциями, то разницы почти никакой. Единственное важное отличие в том, что результат, возвращаемый хранимой процедурой, может быть уже отсортирован.
Re[12]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, 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>Всё это делается на булките с пол пинка без всяких генераций. Подробности здесь.
Спасибо, читаю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[13]: Data Access Layer (EF/Linq2Sql and others)
Согласен. Использовать TVF только из-за того, что stored procedures могут вернуть несколько резалтсетов выглядит странно. Если интересно как студия получает схему резалтсета — создайте dataset, запустите визард, что генерит таблицы по выбранным процедурам (add new table... и поехали) и мониторьте sql profiler'ом. Там нет абсолютно никакой магии.
1. К сожалению при генерации враперов для хранимок генерируется не strongly typed result set а DataTable что конечно не устраивает меня. Раз генерировать Linq1Sql или EF умеют генерировать strongly typed result set — то и такой тул как LLBGenpro тоже должен уметь это делаать. Набивать руками тысячи классов для работы с базой — это нереально.
2. нет поддержки работы с entity через хранимки. Не фатальный конечно недостаток. Мелочь, но неприятная.
3. Шаблоны не слишком умные, например я отключил генерация базового класса для entity, сам базовый класс не сгенерировался но в entity осталось наследование от него. Конечно огорчило меня это сильно, шаблоны оказались туповатые, тоесть совсем. Смысла их в текущей реализации конечно немного.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[18]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Tom, Вы писали:
Tom>Слушай, есть в проекте есть люди которые делают работу через ж@@пу, то тут ничего не спасёт
В том то и дело что спасёт Спасает обычно всякое отсутствие возможности сделать что-либо и через ж@@пу и через ж%%пу и даже через жООпу.
Tom>В моём случае сгенерированные классы править будет просто невозможно. так как билд процесс будет устроен тауим образом, что при каждом билде всё будет генерироваться с нуля. По крайней мере на билд сервере. В общем эта проблема — не наш случай.
Конспектируй.
Tom>Ничего не понимаю, с чего вдруг надо чекаутить пол проекта, и тем более пол проекта забирать. Сейчас например у нас много чего генерируется, спокойно, ничего не чекайтится вообще, и тем более не чекинится. Поясни о чём ты.
У тебя сгенерированные файлы будут включены в проект? Будут. Теперь попробуй из студии сделать Submit для проекта с такими файлами.
Tom>Вот об этом я и писал. Тул который генерирует код должен быть максимально флексибле.
Я об этом тоже писал. Максимально флексибле — это код, написанный руками.
Tom>По поводу генерации и BLToolKit, основная проблема с BLToolKit-ом в том, что нет генерилки и я не могу держать постоянно код up to date с базой. Например я описать какой то ad hoc запрос, думаю это возможно при помощи атрибутов. Реально у меня нет шансов провериро его выполнение в compile time. Ну и генерить entity капкой то другой тулзой для BLToolKit-а выглядит по меньшей мере странно. Вот допустим у нас есть 1000 стор, представь как это будет выглядеть, сгенерировать кучук таких классов, в потом ручками описать все вызовы в акцесорах (.
Я никого не принуждаю здесь использовать булкит. Я тебе рассказываю о проблемах precompile-time генерации кода.
Tom>Всё что можно сгенерировать автоматически — должно быть сгенерировать автоматически.
Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Holms, Вы писали:
K>Так сядь и напиши Для таблиц там вообще нечего делать — работы на час-полтора, с хранимками сложнее, но тоже решаемо. Зато будет тулза, которая удобна вам и делает именно то, что нужно вам, и именно так, как нужно вам...
ну ... дык, я всё слежу за этим топиком, может появится умелец
и еще, я не уверен, но есть ли подержка Linq для BLToolkit, а то забивать текст запроса в програму ОЧЕНЬ неохота, так как при этом нету проверки в compile-time изменений в БД.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
The life is relative and reversible.
Re[19]: Data Access Layer (EF/Linq2Sql and others)
IT>В том то и дело что спасёт Спасает обычно всякое отсутствие возможности сделать что-либо и через ж@@пу и через ж%%пу и даже через жООпу.
Так я как раз про билд сервер и генерацию всего всегда с нуля как раз и говорил, в этом случае жопы быть не может... Могут быть ошибки компиляции в случае есть код и база не синхронизированы, чего собственно нам и нужно.
Tom>>В моём случае сгенерированные классы править будет просто невозможно. так как билд процесс будет устроен тауим образом, что при каждом билде всё будет генерироваться с нуля. По крайней мере на билд сервере. В общем эта проблема — не наш случай.
IT>Конспектируй.
Ок, уговорил
Tom>>Ничего не понимаю, с чего вдруг надо чекаутить пол проекта, и тем более пол проекта забирать. Сейчас например у нас много чего генерируется, спокойно, ничего не чекайтится вообще, и тем более не чекинится. Поясни о чём ты. IT>У тебя сгенерированные файлы будут включены в проект? Будут. Теперь попробуй из студии сделать Submit для проекта с такими файлами.
Да ну это не проблема. Во первых можно включить каталог целмком, во вторых можно включить отдельный сгенерированный msbuild файл, в котором уже подключать сгенерированные файлы. Студия сама много чего генерирует, и нормально с этим сгенерированным контентом работает. В общем это не проблема. А если и доставит какие то трудности то они давольно просто должны решаться, уж точно это не show stopper.
IT>Я никого не принуждаю здесь использовать булкит. Я тебе рассказываю о проблемах precompile-time генерации кода.
Я пока реальных проблем не вижу. Давай вспомним то что ты упоминал:
1. Проблемы со студией (отписал мнение выше)
2. Проблемы с тем что кода надо править — может быть проблемой, но в случае тупой генерилки ((.
Что то ещё?
IT>Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал.
Эээ, а почему она худшая, и как это можно поменять? В моём случае ДО компиляции по базе строятся враперы, чем это плохо и как можно сделать лучше? Я вижу один огромный для меня плюс, сгенерированный код всегда будет up to date. Что даёт очень много бенефитов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[13]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, achmed, Вы писали:
A>Здравствуйте, Flying Dutchman, Вы писали:
FD>>Если же мы сравниваем хранимые процедуры, только возвращающие recordset, с table-valued функциями, то разницы почти никакой. Единственное важное отличие в том, что результат, возвращаемый хранимой процедурой, может быть уже отсортирован.
A>Можно придумать тысячу причин чтобы ограничивать себя использованием функций, только на практике выйдет боком.
Ты меня неправильно понял. Я вовсе не агитирую против использования хранимых процедур в пользу использования табличных функций. Тем более что последние обычно не поддерживаются большинством OR-mapper'ов. Я просто имел в виду, что генератор может более корректно сгенерировать код для представления результата табличной функции, чем для результата хранимой процедуры.
Здравствуйте, Holms, Вы писали:
H>и еще, я не уверен, но есть ли подержка Linq для BLToolkit, а то забивать текст запроса в програму ОЧЕНЬ неохота, так как при этом нету проверки в compile-time изменений в БД.
в процессе, Игорь щас этим усиленно занят
генерация простых запросов есть ужо очень давно (здесь)
Здравствуйте, Tom, Вы писали:
Tom>В общем по поводу LLBGenPro первые мнения.
Tom>1. К сожалению при генерации враперов для хранимок генерируется не strongly typed result set а DataTable что конечно не устраивает меня. Раз генерировать Linq1Sql или EF умеют генерировать strongly typed result set — то и такой тул как LLBGenpro тоже должен уметь это делаать. Набивать руками тысячи классов для работы с базой — это нереально.
Да, это неудобно (хотя я в основном использую для получения данных запросы или представления, а хранимые процедуры использую редко). Я собираюсь связаться по этому поводу с разработчиками LLBLGen, может, они добавят такую возможность.
Tom>2. нет поддержки работы с entity через хранимки. Не фатальный конечно недостаток. Мелочь, но неприятная.
А что такое "Работа с entity через хранимки" и для чего это нужно ?
Tom>3. Шаблоны не слишком умные, например я отключил генерация базового класса для entity, сам базовый класс не сгенерировался но в entity осталось наследование от него. Конечно огорчило меня это сильно, шаблоны оказались туповатые, тоесть совсем. Смысла их в текущей реализации конечно немного.
У LLBLGen есть отдельный дизайнер шаблонов, при помощи которого можно создавать свои шаблоны. Ты его смотрел ? (Сам я с ним никогда не работал, потому что пользовался только стандартными шаблонами и они меня полностью устраивали.)
Re[20]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, Tom, Вы писали:
IT>>Я никого не принуждаю здесь использовать булкит. Я тебе рассказываю о проблемах precompile-time генерации кода. Tom>Я пока реальных проблем не вижу. Давай вспомним то что ты упоминал: Tom>1. Проблемы со студией (отписал мнение выше)
Проблему ты не понял, ну да она быстро всплывёт.
Tom>2. Проблемы с тем что кода надо править — может быть проблемой, но в случае тупой генерилки ((.
А у тебя будет какая?
IT>>Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал. Tom>Эээ, а почему она худшая,
Потому что она генерирует императивный код, который можно изменить руками и сильно в этом преуспеть, а потом потерять все изменения даже этого не заметив.
Tom>и как это можно поменять?
Можно попробовать генерировать код, который будет нельзя или бессмысленно менять. Например, если генерировать только декларативные конструкции без императива.
Tom>В моём случае ДО компиляции по базе строятся враперы, чем это плохо и как можно сделать лучше? Я вижу один огромный для меня плюс, сгенерированный код всегда будет up to date. Что даёт очень много бенефитов.
Ты пытаешься решить проблему синхронизации кода с БД и одновременно генерацию кода аксессоров, но тебе на самом деле важнее первое. Второе лишь средство, но средство плохое. Вот над ним нужно поработать и убрать потенциальные проблемы. Повторю проблемы ещё раз.
1. Потенциальная (и главное непредсказуемая) возможность менять императив в сгенерированном коде.
2. Проблемы с соурс-контролом.
Что касается самого генератора, который ты пытаешься найти под себя, то его легче написать самому. На это ушло бы в три раза меньше времени, чем мы тут потраили на трёп и результат был бы такой, какой нужен именно тебе.
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Data Access Layer (EF/Linq2Sql and others)
FD>Да, это неудобно (хотя я в основном использую для получения данных запросы или представления, а хранимые процедуры использую редко). Я собираюсь связаться по этому поводу с разработчиками LLBLGen, может, они добавят такую возможность.
Смотри форум, я это обсуждение поднял уже.
Tom>>2. нет поддержки работы с entity через хранимки. Не фатальный конечно недостаток. Мелочь, но неприятная. FD>А что такое "Работа с entity через хранимки" и для чего это нужно ?
CRUD с использованием хранимок. Нужно для разных целей. Это отдельный разговор.
Tom>>3. Шаблоны не слишком умные, например я отключил генерация базового класса для entity, сам базовый класс не сгенерировался но в entity осталось наследование от него. Конечно огорчило меня это сильно, шаблоны оказались туповатые, тоесть совсем. Смысла их в текущей реализации конечно немного.
FD>У LLBLGen есть отдельный дизайнер шаблонов, при помощи которого можно создавать свои шаблоны. Ты его смотрел ? (Сам я с ним никогда не работал, потому что пользовался только стандартными шаблонами и они меня полностью устраивали.)
Дизайнер не успел ещё посмотреть но не гибкость шаблонов меня уже смутила ((( В принципе я описал свой case. Я пологал что шаблоны сделаны на основе модификации AST. А они на порядок тупее ((((
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[21]: Data Access Layer (EF/Linq2Sql and others)
IT>Проблему ты не понял, ну да она быстро всплывёт.
Ну дык обрисуй если я не понял
Tom>>2. Проблемы с тем что кода надо править — может быть проблемой, но в случае тупой генерилки ((. IT>А у тебя будет какая?
Дык я же вумную ищу
IT>>>Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал. Tom>>Эээ, а почему она худшая, IT>Потому что она генерирует императивный код, который можно изменить руками и сильно в этом преуспеть, а потом потерять все изменения даже этого не заметив.
Игорь, мы не будем менять сгенерированный код, и даже в SCM его класть не будем
Tom>>и как это можно поменять? IT>Можно попробовать генерировать код, который будет нельзя или бессмысленно менять. Например, если генерировать только декларативные конструкции без императива.
А, ну теперь ход мыслей понятен
Tom>>В моём случае ДО компиляции по базе строятся враперы, чем это плохо и как можно сделать лучше? Я вижу один огромный для меня плюс, сгенерированный код всегда будет up to date. Что даёт очень много бенефитов.
IT>Ты пытаешься решить проблему синхронизации кода с БД и одновременно генерацию кода аксессоров, но тебе на самом деле важнее первое. Второе лишь средство, но средство плохое. Вот над ним нужно поработать и убрать потенциальные проблемы. Повторю проблемы ещё раз.
IT>1. Потенциальная (и главное непредсказуемая) возможность менять императив в сгенерированном коде.
Как писал выше — отпадает. Руками абсолютно точно никто ничего менять не будет.
IT>2. Проблемы с соурс-контролом.
Так и не понят какие.
IT>Что касается самого генератора, который ты пытаешься найти под себя, то его легче написать самому. На это ушло бы в три раза меньше времени, чем мы тут потраили на трёп и результат был бы такой, какой нужен именно тебе.
Чукча постарел, обзавёлса жирком на бочках и уже давно не учавствует в велосипедных гонках. Да и есть у меня сомнения в том что оно можно быстро написать. Да и зачем если есть уже готовые решения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[15]: Data Access Layer (EF/Linq2Sql and others)
IT>А сомнений в том, что ты найдёшь не совсем то, что тебе нужно у тебя нет? Да и на настройку стандартного велосипеда у тебя уйдёт не меньше времени, чем на написание своего собственного. http://andir-notes.blogspot.com/2009/02/t4-visual-studio.html
На самом деле при такой постановке как была в первом постее вообще не очень понятно что было нужно. Только в процессе длительного общения выяснилось что вполне достаточно решения задач кодогенерации.
Re[13]: Data Access Layer (EF/Linq2Sql and others)
A>Только не мало писать, что код надо было разнести по разным процедурам и вызывать из последовательно. Нельзя, потому процедура это контракт между между приложением и БД.
Только врядли в случае использования LINQ
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Re[16]: Data Access Layer (EF/Linq2Sql and others)
Здравствуйте, ili, Вы писали:
ili>Здравствуйте, Holms, Вы писали:
H>>и еще, я не уверен, но есть ли подержка Linq для BLToolkit, а то забивать текст запроса в програму ОЧЕНЬ неохота, так как при этом нету проверки в compile-time изменений в БД.
ili>в процессе, Игорь щас этим усиленно занят ili>генерация простых запросов есть ужо очень давно (здесь)
Честно говоря чем дальше думаю тем больше понимаю что нифига козе баян не нужен
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Tom, Вы писали:
Z>Как я понял нужен просто data mapper и генерилка POCO и маппингов. Как маппер можно использовать iBatis, BLToolkit даже NHibernate не заставляет тебя использовать больше его возможностей чем требуется. Осталось выбрать генерилку маппингов и сущностей по схеме базы. MyGeneration, CodeSmith, ddl2hbm.
Вполне рабочий вариант. Я в своем проекте использую комбинацию BLToolkit + CodeSmith. Генерятся классы по полям таблиц (с возможностью навигации по родительским и дочерним сущностям), стандартные ХП (ins, upd, del), враперы процедур, в том числе и тех, которые возвращают 1 и более rрезультсетов, аксессоры для таблиц. Кроме того для не зацикленных наборов таблиц можно сгенерить автоматический апдейтер, который учитывает зависимости между таблицами. Все сущности, коллекции и хранилища коллекций прекрасно передаются через WCF. Любой шаблон в случае необходимости можно изменить.
Если нам не помогут, то мы тоже никого не пощадим.
не забудьте поделиться результатами
) 
