Осталось дело за малым, аргументировать использование BLToolkit группе архитекторов и коллегам.
Лично для меня максимально интересна поддержка LINQ & DML.
Но у булкита за время его жизни отросло как я понимаю огромное количество фичей.
Вопрос, те кто использует BLToolkit, опишите наиболее важные лично для вас фичи.
Tom>Вопрос, те кто использует BLToolkit, опишите наиболее важные лично для вас фичи.
Пользовал. Правда линка тогда небыло ещё.
Доступность сорцов. Простота
Здравствуйте, Tom, Вы писали:
Tom>Хочется прибыть в ваш полк
Так и не нашёл ничего человеческого?
Tom>Осталось дело за малым, аргументировать использование BLToolkit группе архитекторов и коллегам.
Я бы начал с объяснения разницы по сравнению с другими ORM инструментами. Можно начать отсюда.
В качестве дополнительных аргументов:
— самый быстрый на сегодняшний день ORM в .NET мире;
— самый богатый список поддерживаемых БД;
— возможность непосредственно влиять на состав фич библиотеки.
Tom>2IT, Тут http://bltoolkit.net/Doc.LinqExtensions.ashx DML так скромно описан, это надо рекламировать как Killer Feature!
Это как раз является следствием принятого подхода. Мы не скрываем БД от программиста, мы предлагаем инстумент облегчающий работу с ней.
Если нам не помогут, то мы тоже никого не пощадим.
Tom>>Хочется прибыть в ваш полк IT>Так и не нашёл ничего человеческого?
IT>Я бы начал с объяснения разницы по сравнению с другими ORM инструментами. Можно начать отсюда.
Уже
IT>В качестве дополнительных аргументов: IT>- самый быстрый на сегодняшний день ORM в .NET мире;
В принципе это важно, хотя конечно в среднестатистических проектах тормоза в основном в БД.
В любом случае скорость это конечно плюс.
IT>- самый богатый список поддерживаемых БД;
Для среднестатистического проекта использутся одна БД, у нас сиквел только.
IT>- возможность непосредственно влиять на состав фич библиотеки.
Хороший пункт.
Tom>>2IT, Тут http://bltoolkit.net/Doc.LinqExtensions.ashx DML так скромно описан, это надо рекламировать как Killer Feature! IT>Это как раз является следствием принятого подхода. Мы не скрываем БД от программиста, мы предлагаем инстумент облегчающий работу с ней.
Это для меня понятно, надеюсь конечно что остальные тоже поймут...
Здравствуйте, Tom, Вы писали:
IT>>- самый богатый список поддерживаемых БД; Tom>Для среднестатистического проекта использутся одна БД, у нас сиквел только.
В принципе да, но определённые 'но', всё же существуют. Для внутренных проектов скорее всего одна БД и другой не надо. Тем не менее, если раньше мы у себя даже не думали о том, чтобы соскочить с Sybase прежде всего по причинам переноса кода на другую СУБД, то сегодня мы такую возможность рассматриваем вполне серьёзно и портирование кода для нас главное проблемой совсем не является. Для внешних проектов практически бесплатная алтернатива в плане БД может оказаться не таким уж и маленьким плюсом. Взять тот же Янус, в нём AVK выбросил всю БД специфику, кроме DDL и один code base используется для 4-х или 5-ти БД.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Вопрос, те кто использует BLToolkit, опишите наиболее важные лично для вас фичи.
LINQ, поддержка апдейтов, возможность использования модели, описанной только интерфейсами, возможность создания кастомных LINQ-подзапросов в виде функций.
Главный недостаток — конфигурация в статиках и монстроидальность DBManager.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>возможность создания кастомных LINQ-подзапросов в виде функций.
А можно по подробнее что это такое?
AVK>Главный недостаток — конфигурация в статиках и монстроидальность DBManager.
Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов.
Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца
Здравствуйте, Tom, Вы писали:
AVK>>возможность создания кастомных LINQ-подзапросов в виде функций. Tom>А можно по подробнее что это такое?
http://www.rsdn.ru/projects/rfd/linq/LinqWithBLToolkit.xml#EISAG
AVK>>Главный недостаток — конфигурация в статиках и монстроидальность DBManager. Tom>Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов. Tom>Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца
Настройки и так в отдельном классе, часть из них конфигурируется через config-файл. Но видимо этого недостаточно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Настройки и так в отдельном классе, часть из них конфигурируется через config-файл. Но видимо этого недостаточно.
Должна быть возможность одновременного существования в рамках одного домена нескольких конфигураций. Сейчас для этого приходится писать не очень красивый и потенциально ненадежный код. А уж через файл оно, или там подпиской на статические события, не столь важно.
Вот погляди на WCF — я могу конечно понаписать мегаконфиг и законфигурить все в нем, могу даже констрейнты программно на этот конфиг наложить. Но при этом я могу взять и собрать конфигурацию программно (см. классы ХххBindingElement для примера), и подсунуть ее конкретному экземпляру ServiceHost, наплевав на все эти конфиги. Вот последнее в BLT до сих пор не очень получается. По идее нужно всю конфигурацию передавать экземпляру DBManager, а из статиков ее брать не напрямую, а специальным отдельным хелпером, т.е. ввести промежуточную абстракцию. Это снизит связность и решит большинство проблем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, Tom, Вы писали:
AVK>>Главный недостаток — конфигурация в статиках и монстроидальность DBManager. Tom>Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов.
Да дело не только и не столько в интерфейсах. Там целый ряд рефакторингов нужен. Во-первых выдрать из него кучу хелперов во внешний класс (но сейчас это не очень получается из-за странноватой реализации некоторых методов, которые мне не очень понятно как распутывать). Во-вторых тщательнее отнестись к SRP — DBManager сейчас слишком большой responsibility обладает. Например, инкапсулирует в себе и фабрику коннекшенов, и собственно коннекшен, что сильно пудрит смысл в коде. IT все хочет ввести некий DataContext, но я пока не до конца его мысль понимаю.
И таки да, нужно вводить по крайней мере один интерфейс, чтобы хотя бы формально можно было отодрать всю реализацию BLT из публичных контрактов использующей его сборки.
Tom>Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца
Но чем позже эту песню запеть, тем больше и геморойнее ее петь придется. Ну да я просто назвал лично для меня самые основные pain points в дизайне BLT. На истину в последней инстанции не претендую.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Tom, Вы писали:
AVK>>>Главный недостаток — конфигурация в статиках и монстроидальность DBManager. Tom>>Это конечно не айс и совсем не SOLID, можно начать с того что бы унаследовать его от нескольких логически не связанных интерфейсов.
AVK>Да дело не только и не столько в интерфейсах. Там целый ряд рефакторингов нужен. Во-первых выдрать из него кучу хелперов во внешний класс (но сейчас это не очень получается из-за странноватой реализации некоторых методов, которые мне не очень понятно как распутывать). Во-вторых тщательнее отнестись к SRP — DBManager сейчас слишком большой responsibility обладает. Например, инкапсулирует в себе и фабрику коннекшенов, и собственно коннекшен, что сильно пудрит смысл в коде. IT все хочет ввести некий DataContext, но я пока не до конца его мысль понимаю.
Согласен, фабрика конекций и сама конекция вообще в один класс не лезет.
А BLT вообзе извне транзакцию можно передать? А то у нас своя реализация TransactionScope-а, в которой отсуствует фатальный недостаток
AVK>И таки да, нужно вводить по крайней мере один интерфейс, чтобы хотя бы формально можно было отодрать всю реализацию BLT из публичных контрактов использующей его сборки.
А DBManager не реализует интерфейса вообще??? Это же как мы его будем тогда в DI испольщовать? на самом деле если это так — то это show stoper (.
Tom>>Потом их можно попытаться вынести в отдельные классы. Вообще это конечно пестня без конца AVK>Но чем позже эту песню запеть, тем больше и геморойнее ее петь придется. Ну да я просто назвал лично для меня самые основные pain points в дизайне BLT. На истину в последней инстанции не претендую.
Согласен полность, чем позже начинаешь прислушиваться к таким вещим как SRP и DI тем дольше и мучительнее приходится рефакторить. При этом рефакторить всё равно придётся.
Здравствуйте, Tom, Вы писали:
Tom>А BLT вообзе извне транзакцию можно передать?
BLT вообще очень мало что с транзакциями что то делает, есть лишь очень тонкая обертка над ними.
Tom>А DBManager не реализует интерфейса вообще???
Не реализует. Причем без использования конкретного класса DBManager в публичных контрактах не обойтись в принципе.
Tom> Это же как мы его будем тогда в DI испольщовать?
Опосредованно. Сервис свой, а уж у него есть метод получения DBManager.
Tom> на самом деле если это так — то это show stoper (.
Не думаю. Просто не очень красиво, но не более того. Шансов на появление альтернативных реализаций, хорошо совместимых с BLT, практически нет. Специфика LINQ — слишком много неоднозначностей возникает.
Tom>Согласен полность, чем позже начинаешь прислушиваться к таким вещим как SRP и DI тем дольше и мучительнее приходится рефакторить. При этом рефакторить всё равно придётся.
Да дело не только в DI. Вон в янусе как такового полномасштабного DI фреймворка нет. Тем не менее модель у него предполагает в определенной степени гибкость и расширяемость. И этого достаточно, чтобы в свое время пришлось втискивать в нее BLT долго и больно. Особенно задолбала война со статиками. Некоторые углы, в итоге, у BLT пришлось подтесать, но текущая ситуация от совершенства еще очень далека.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>Опосредованно. Сервис свой, а уж у него есть метод получения DBManager.
А толку. Если интерфейса нет — значит и stub не написать
Tom>> на самом деле если это так — то это show stoper (. AVK>Не думаю. Просто не очень красиво, но не более того. Шансов на появление альтернативных реализаций, хорошо совместимых с BLT, практически нет. Специфика LINQ — слишком много неоднозначностей возникает.
Я имел ввиду что мы стараемся идти к SOLID соответственно повсеместно использовать DI, а базовый тул который не реализует ни одного интерфейса — это проблема.
AVK>Да дело не только в DI. Вон в янусе как такового полномасштабного DI фреймворка нет. Тем не менее модель у него предполагает в определенной степени гибкость и расширяемость. И этого достаточно, чтобы в свое время пришлось втискивать в нее BLT долго и больно. Особенно задолбала война со статиками. Некоторые углы, в итоге, у BLT пришлось подтесать, но текущая ситуация от совершенства еще очень далека.
Здравствуйте, pr0ff, Вы писали:
P>Здравствуйте, Tom, Вы писали:
Tom>>2IT, Тут http://bltoolkit.net/Doc.LinqExtensions.ashx DML так скромно описан, это надо рекламировать как Killer Feature!
P>Никакого Killer Feature, это и вM$ LINQ to SQL возможно
Пример в студию
Здравствуйте, Tom, Вы писали:
AVK>>Опосредованно. Сервис свой, а уж у него есть метод получения DBManager. Tom>А толку. Если интерфейса нет — значит и stub не написать
А зачем тебе stub для DBManager? Для тестов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>А зачем тебе stub для DBManager? Для тестов?
Да не только для тестов.
Допустим DBManager является фабрикой конекций, и мне нужно использовать данную фичу.
Я с бОльшей радостью передам в класс/метод маленький интерфейс аля IConnectionFactory который реализует пару методов вместо огромного класса DBManager.
Здравствуйте, Tom, Вы писали:
Tom>Хочется прибыть в ваш полк
простота, расширяемость, возможность делать то, что надо мне и так, как я считаю это нужным, возможность свалить часть своей работы на IT, поклянчив фичу
зимой планирую таки перетащить проект под LINQ, надо сделать поддержку разных БД (не то что бы я хотел, а жизнь заставляет )
из минусов — оно конечно все просто, но учиться приходится не по учебникам а в "бою" (я в свое время чуть не посидел, пока юнит-тесты как доки читать научился... хотя это тоже был полезный опыт).
Если нам не помогут, то мы тоже никого не пощадим.
