IoC в веб

Да ладно, в ASP.NET MVC вон сколько их на выбор: unity, ninject'ы всякие. Но применять нужно к месту, во многих проектах без них можно спокойно обойтись, либо использовать свой велосипед, типа сервис локаторов.

иногда они иначе называются. во многих языках они просто не нужны, тут уже ентерпрайз головного мозга начинается

В быдло-фреймворках обычно слишком мало слоев, да и вообще архитектура примитивная и фиксированная. IoC подразумевает гибкость, а модные фреймворки напротив основаны на фиксированной архитектуре. Как-то один из консультантов по Agile поведал нам такое наблюдение: чем меньше чудных фреймворков, тем лучше. Ioc и библиотеки - наши друзья. Но это касается сереьезных проектрв, визитки как раз нужно на всяких рельсах писать.

тут уже ентерпрайз головного мозга начинается

при том что IoC легковесная и простая концепция

IoC не коррелирует с размером проекта, it's just how applications should be build на уровне принципа. Пускай из трех классов и пускай без IoC фреймворка как такового

Хм, я думаю вот как: если для говно-сайтика еще можно зафигачить всю логику в контроллерах (которые интсанциируются фреймворком) путем дергания методов ActiveRecord-моделей (читай сервис-layer в который что-то нужно инъектить не нужен), то написать большой проект в таком стиле попахиает первой версией twitter фиаско.

Symfony 2, Zend Framework 2 - оба на PHP, оба с полноценным DI.

В Yii тоже есть своя реализация IoC, которая не заостряет внимания собственно на самом IoC. Это приятно, потому как в ZF2 и Symfony2 DI засунули везде, куда только можно было его засунуть (не всегда гуд).

ну ты просто приведи пример где их нет а они нужны? простота ее ведь подразумевает простое внедрение в любой код?

Какой профит? Для разработчика может быть, а со стороны железа профита особо нет. При увеличении нагрузки на сервис врядли будет линейно расти количество оборудования при IoC и Java.

ну ты просто приведи пример где их нет а они нужны?

На любом сайте (от визитки до распределённой системы).

Любой сайт обязательно должен иметь юнит-тесты основной логики и функций (функциональные тесты тоже желательно бы). Объяснять, почему так полезно иметь тесты не нужно никому. А вот правильный IoC повышает очень сильно пригодность кода к тестируемости и переносимости очень простыми приёмами.

Например, мы реализовали паттерн ActiveRecord. В объект нашей реализации ActiveRecord мы инжектируем экземпляр объекта класса соединения с РСУБД через конструктор (ctor injection; setter injection не подойдёт, потому что зависимость обязательная).

Для обычной веб-части системы мы инжектируем объект соединения, связанный с PgSQL к примеру, а вот юнит-тесты пускаем на SQLite и потому инжектировать в AR-объект нужно другое соединение, настроенное уже для работы с SQLite.

Какой профит? Для разработчика может быть, а со стороны железа профита особо нет. При увеличении нагрузки на сервис врядли будет линейно расти количество оборудования при IoC и Java.

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

Это ортогональные вещи.

простота ее ведь подразумевает простое внедрение в любой код?

IoC действительно прост:

$object = new Class();
$service = new Service();
$object->service = $service; // это за нас делает IoC-контейнер, как именно делает: зависит от него

Так вроде twitter никогда не жалел, что начал с rails? Надо посискать пруфы, но было интервью с ведущим(и) разработчикам(и), где был развернут этот вопрос.

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

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

Ну вообще да, мой комментарий малость не в тему, про простоту IoC. :)

Твоя ТЗ мне понятна. Солидарен с dizza, нужно просто не использовать такие фреймворки, которые вставляют палки в колёса на пути к правильному подходу.

Недавно искал такие фремворки для Scala. Это не пыхопе или руби, и в главном фреймворке языка - Lift, все равно rails пошлости

Так вроде twitter никогда не жалел, что начал с rails?

Да наверняка у них так и планировалось: вначале берём средство для очень быстрого старта, параллельно разрабатывая более вдумчиво что-то получше и посолиднее. Свою задачу RoR (очень быстрый старт проекта) выполнил у них отлично.

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

Лишний абстрактный слой - лишние вызовы, может у тебя там 100500 сисколов вылезет и еще куча интересный вещей. При больших нагрузках лучше все прибивать гвоздями, вплоть до конфигов.

Все таки Java это больше ынтырпрайз, где не такие большие нагрузки. Поставщик оборудования на прошлой работе раз в несколько месяцев отгружал по 500 серверов одной социальной сети, которая была написана на Java. У нас же было около 10 серверов, которые при росте количество пользователей где-то в 100 раз практически не ощутили нагрузки. Да, C++ приложение труднее поддерживать. Тем более в нем не было никаких ORM, СУБД популярных итд.

it's just how applications should be build

builT. Пиши на родном языке, не выпендривайся.

Пиши на родном языке, не выпендривайся.

Это очень сложно для всемирно известного ООП-архитектора, десять лет прожившего в Калифорнии.

Но это касается сереьезных проектрв, визитки как раз нужно на всяких рельсах писать.

Популярные сайты на Rails

Basecamp
Github
Hulu
Scribd
Shopify
Yellowpages.com
Danbooru
Groupon
Look At Me

Не используют значит им не нужно. Всё просто.

Rails - это религия. Будем уподобляться фанатикам?

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

Вот это может быть, да. Я тоже об этом думал. Но разве не понавыдумывали умных всяких там рантаймов и т.д? Например тот же connection pool или что там у них должен быть инстанциирован в памяти постоянно?

Rails - это религия.
Будем уподобляться фанатикам?

/0, разве нет? Rails вполне годный фреймфорк. Что вам не нравится это другое дело.

например пхп, получается объект нужно создавать каждый раз когда скрипт дергают, что, возможно, сильно уменьшает профит от использования DI

Почитай про кэширование в PHP. IoC-контейнеры в PHP давным давно юзаются (1, 2). Особого ухудшения производительности не дают (при условии, что используем opcode-кэшировщик, вроде APC).

То, что скрипт парсится каждый раз заново — это мнение дилетантов и людей, не захотевших почитать маны о PHP. :)

не очень вас понял. здесь речь идет о том, что конфигурирование ioc-контейнера осуществляется в момент деплоймента. объекты могут быть созданы и храниться в памяти на момент прихода запроса. причем любые объекты, в том числе и сетевые соединения. более того, конфигурирование объектов может так же оказаться не совсем тривиальным действием, например, в случае, использования АОП. APC тут не причем, тут имелось в виду, что оно в джаве, по другому, работает.

«Вполне годен» - для крупных проектов нельзя рассуждать в категориях вполне годен. Мой пойнт в том, что слишком у него все гвоздями прибито.

я знаю что такое ioc, как он прост и зачем его использовать. я говорю что раз его где-то нет то там он просто не востребован, а если тебе нужно то куда его не включили то бери и внедряй, все ведь просто, как-то так

я говорю что раз его где-то нет то там он просто не востребован,

Или просто там не знают о его существовании. Мы теорию учим через практику. Я думаю, что тех, кто узнал про IoC из книг сильно меньше чем тех, кто узнал про него работая с каким-то модным фреймворком. Если твой выбор пал на модный Spring, то ты будешь знать что такое IoС, а если выбор пал на еще более модный Rails, то не будешь.

Этот та Scala, которая не умеет парсить аннотации в рантайме? Какой синтаксис для IoC предлагаешь для скалы?

Cake pattern? Аннотации в рантайме - для нубов )) Шучу, вообще там глуповатая история, они запилили свои аннотации в чем то круче по их словам, но я так не понял почему, потому отношусь к этому скептически. Но рантайм аннотации не работают. Нет синтаксиса. В итоге надо саму аннотацию писать на Java c помощью обычного Java синтаксиса, но применять в Scala коде. Это работает.

Ну я в Play хотел по хардкору перейти целиком на скалу, но мне нужно перед стартом сервера генерить некую инфу по классам (как минимум, схему для поиска по БД). И вышел фейл, потому что в жаве-скале ничего кроме аннотаций для хранения метаданных нету, а в Скале аннотации не работают, а если юзать жаваклассы это ломает scala-only подход :((

а в Скале аннотации не работают

Они работают, если сама рантайм аннотация написана на Java. Саму аннотацию нельзя написать на Scala, только на Java. Но если влепить в Scala коде @Autowired, то он будет работать