Comments 12
Даже как-то не важно что в статье — за КДПВ пять! :)
Я как гляну на ваши С++ после C# мне аж плохо становится. Как же вы себя мучаете. Здесь каждая строчка — боль.
Ну C++ программеры как фанаты серии игр (Demon|Dark) Souls. Хоть и боль, зато какое удовольствие. Сам перешел сейчас на C#, пока не могу найти времени и дописать IoC-контейнер для C++, не хватает пока резолва списка сервисов и внедрения в свойства. Да и в отличии от C# еще добавлена поддержка динамической загрузки библиотек из коробки, как на C# не катит. Там знатный разврат с шаблонами, но когда оно работает, да еще и при этом на этапе компиляции, удовольствие знатное.
Я тоже попеременно переключаюсь с C++ на C# и обратно. И таки да — полностью с Вами согласен, все C++ программисты мазохисты. Но однажды вкусив сего удовольствия забыть его невозможно. Сразу вспоминается фраза из видео про Гитлера о C++17: «And the worst thing is… I still like C++».
Да и в отличии от C# еще добавлена поддержка динамической загрузки библиотек из коробки, как на C# не катит.
Почему вы считаете, что в C# нет возможности динамически загрузить библиотеку из коробки?
Там знатный разврат с шаблонами, но когда оно работает, да еще и при этом на этапе компиляции, удовольствие знатное.
А в чем польза от IoC в режиме компиляции? Зачем мне заморачиваться с контейнерами и разрешениями ссылок в режиме компиляции, если они уже на стадии компиляции известны и определены и могут быть использованы без IoC контейнера?
> Почему вы считаете, что в C# нет возможности динамически загрузить библиотеку из коробки?
А я не говорил, что нет. Просто в C# я к примеру связывал тот же Autofac и MEF, чтобы не писать велосипедов, здесь решил сделать всё сразу.
> А в чем польза от IoC в режиме компиляции?
Ну я грубо выразился, на деле часть кода раскрутки зависимостей генерируется в compile-time. У меня разделение на Каталог и собственно сам Контейнер, в каталогах большая часть в compile-time, в контейнере уже рантайм. А с другой стороны затем же, зачем и в C#, как бы регистрация сущностей в большинстве случаев не динамическая и все зависимости известны на этапе компиляции, так зачем в C# используют IoC-контейнеры?
А я не говорил, что нет. Просто в C# я к примеру связывал тот же Autofac и MEF, чтобы не писать велосипедов, здесь решил сделать всё сразу.
> А в чем польза от IoC в режиме компиляции?
Ну я грубо выразился, на деле часть кода раскрутки зависимостей генерируется в compile-time. У меня разделение на Каталог и собственно сам Контейнер, в каталогах большая часть в compile-time, в контейнере уже рантайм. А с другой стороны затем же, зачем и в C#, как бы регистрация сущностей в большинстве случаев не динамическая и все зависимости известны на этапе компиляции, так зачем в C# используют IoC-контейнеры?
А тут, знаете ли, как с чистокровным гуманитарием, который смотрит на неопределенный интеграл или ряд Тейлора — в каждой строчке боль.
Упомяну, что по теме есть еще такая штука как odb. Судя по описанию сделана хорошо. Но лицензия — GPL + коммерческая.
Мда. лицензия отпугивает. Из хороших современных ORM недавно наткнулся еще на Sqlpp1. Сейчас активно развивается сообществом.
Ещё есть такая библиотечка, SOCI. Это не ORM, но на ней удобно написать свою.
Честно говоря сомнительное удобство — использовать надстройку, чтобы написать еще одну надстройку. Там могут быть очень тонкие различия в реализации казалось бы одних и тех же операций разными вендорами СУБД, так что при приведении к общему знаменателю мы рано или поздно упремся в ограничения нижестоящей надстройки.
Но мне нравится, как у них сделана расширяемость пользовательскими типами, попробую что-нибудь подобное сделать.
Но мне нравится, как у них сделана расширяемость пользовательскими типами, попробую что-нибудь подобное сделать.
Sign up to leave a comment.
Очередная Reflection Library и ORM для C++