Сваи применяют везде. Это универсальный способ. На них стоит все, от мостов до домов.
Плюсы свай — быстрый монтаж. Фактически, вы уже через день получаете готовый фундамент и можете на нем строить.
С бетонным такая штука не пройдет. Минимум месяц.
Еще один плюс — отсутвтсие подготовительных работ на участке. Просто приезжает трактор и вкручивает, а свай потом подрезаются по нужной высоте. И ничего никто не разравнивает.
Самый жирный минус — отсутствие погреба и хозяйственного помещения под домом. Но если проект этого не предусматривает — сваи являются отличным решением.
Но все становится интереснее, если вспомнить слово «foundry». По какому-то странному стечению обстоятельств, слово это означает «производство» (в смысле синонима слов завод и фабрика) и относится к работе с металлом, как правило, жидким в какой-то момент в процессе.
В случае с Convention over Configuration, описанном в этой статье, DI-container все еще присутствует, он никуда не делся. Просто объекты в нем регистрируются автоматически, а не вручную.
Так что говорить, что DI-container это ненужный промежуточный шаг — некорректно.
Среди приверженцев принципов DI, есть и альтернативный взгляд на DI-container'ы, который сводится к тому что DI-container это промежуточный шаг между Poor mans DI и Convention over configuration, который сам по себе не очень-то нужен
Вот есть небольшая статья на эту тему: blog.ploeh.dk/2012/11/06/WhentouseaDIContainer
Контейнер остаётся контейнером. В качестве зависимости в отдельных компонентах он пробрасывается, чтобы частично решить проблему переноса зависимости. Скажем, модулю на 3-м уровне нужно 9 зависимостей. Проще пробросить контейнер, чем эти 9 зависимостей тащить из контейнера от точки входа.
Да, сценарий использования похож на типичное использование сервис локатора со стороны зависимого модуля, но решение другое, сервис локатор не управляет жизненным циклом сервисов в общем случае, сервисы регистрируются в нём сами или их регистрируют их создатели, контейнер же создаёт их имея какое-то описание как создавать.
А как код проекта может не зависеть от DI-контейнера я вообще не представляю. Вернее представляю, но только в случае широкого использования метапрограммирования, заменяющего, например, new UserManager на вызов Container::getInstance().get('UserManager'). Как-то нам нужно получать из контейнера то, что мы хотим хотя бы на уровне точки входа в приложение, если пробрасывание десятков зависимостей нас не страшит.
Контейнер, использумый таким образом является не DI-контейнером, а service-locator'ом. При нормальном использовании DI-container'а код проекта вообще не зависит от DI-container'а.
Как-то спутаны плюсы DI и DI-контейнера. DI-контейнер и зависмости от него — это цена, которую нужно платить за удобное использование DI, прежде всего за решение проблемы переноса зависимостей. Причём проблема решается лишь частично — сам контейнер становится зависимостью которую нужно пробрасывать вместо реальных зависимостей. При этом реальные зависимости становятся менее явными, особенно в языках с утиной динамической типизацией, где реальный тип может вообще не появляться в коде, только this.container.get('someservice').run()
Возможность запросить подключение к БД из слоя представления говорит о том, что Вы и без контейнера сможете создать его вручную, если действительно захотите.
Но, например, в c# если подключение к БД и слой представления разнести по разным проектам, то можно ограничить область видимости и без хаков в виде рефлексии Вы на слое представления не сможете получить БД вообще никак
Поскольку из контейнера можно получить любой объект, то, например, можно достать соединение с БД из слоя представления, хотя помещено оно туда было для слоя модели. В ситуации «нужно вчера» это может оказаться самым эффективным решением какой-то проблемы в краткосрочной перспективе.
Например, если в коде есть несколько слоев, то можно легко их и непринужденно нарушать.
Для больших проектов, есть резонный повод использовать готовую реализацию, а вот для библиотек контейнер вреден, на мой взгляд, у тебя возникнет протест, когда у тебя в проекте есть уже одна библиотека, которая реализует контейнер, а в зависимостях другая
Думаю, это хороший повод для дискуссии. Допустим, в начале проекта мы делаем DI вручную. В какой-то момент код, занимающийся созданием объектов, станет настолько обширным, что работать с проектом станет неудобно. Тогда мы встанем перед выбором: продолжать накручивать самодельные несистематические костыли или использовать для управления зависимостями контейнер.
Допустим, мы выбрали контейнер. И даже то, что мы получим зависимость от контейнера, будет плюсом. Даже двумя (как минимум). Мы получим: 1) единый «центр управления» — контейнер упростит создание экземпляров и их внедрение (это очевидное преимущество), 2) мы будем использовать «хорошую» зависимость.
Под «хорошей» зависимостью я в данном случае понимаю то, что контейнер поставляется в виде внешней библиотеки. Код контейнера, очень вероятно, будет построен по принципам открытого ПО. Это точно верно для всех контейнеров, упомянутых в статье. Это значит, что этот код будет доступен и многократно перепроверен сообществом.
Не будем отрицать: принципы ООП, это действительно инкапсуляция, наследование и полиморфизм:). Однако, можно сказать, что все они связаны с управлением зависимостями. Да, есть вариант разрешения зависимостей внутри класса, но это ведет к негативным последствиям, описанным в разделе «почему зависимости плохо». Де-факто такой подход устарел, и ему на смену пришло «внедрение зависимостей». На этой теме сфокусирована еще одна статья от этого автора. Над ее переводом я сейчас работаю. Приглашаю познакомиться с ней, думаю, что там Вы найдете еще интересные доводы в пользу DI.
А я всю жизнь думал, что инкапсуляция, наследование и полиморфизм :) Внедрение зависимостей появилось (читать: начало активно использоваться) гораздо позже, по причине, неплохо описанной в данной статье. Взять тот же Turbo Vision — там даже интерфейсы не использовались (они появились позже), и тем не менее Turbo Vision — это ООП. Кстати, «Внедрение зависимостей», вероятно, стоило бы называть «внедрение независимостей», это лучше отражает суть.
Согласен, что создание объекта для пользовательской информации визуально упростит код. Однако, что-то мне подсказывает, что таким образом мы создадим еще одну сущность, которая будет зависеть от HttpServletRequest, получая все его данные. То есть мы встроим еще один слой абстракции, через который метод login буден по-прежнему зависеть от HttpServletRequest, но уже опосредованно.
Если число параметров метода login не будет изменяться в сторону повышения, думаю, лучше оставить строки, как есть. Однако, если число параметров вырастет за 4 (моя личная граница удобства), то объект лучше создать.
В данном конкретном случае хорошо было бы создать какой-то UserCreds объект, конструктор/фабричный метод которого из http запроса вытягивает нужные поля, а login получает его единственным параметром. С одной стороны, мы сделаем минимально необходимую зависимость login, с другой сведём вызов в веб-контроллере или его аналоге к user.login(UserCreds:createFromHttpRequest(request), что заметно проще вызова со строковыми интерфейсами. С третьей стороны, мы закладываем фундамент и под другие способы логина, а не только логин/пароль, и под другие API логина, а не только веб, например через cli или событие в MQ.
ну, с одной стороны да. К примеру на OEL 6 уже ядро 4.1 с гордым названием «unbreakable».
С другой стороны, если посмотреть когда и зачем вообще создавалось такое понятие как дистрибутив, — будет ясно, что дело-то совершенно непростое. Как уже было описано выше
```
Буквально все, от новой версии glibc и вплоть до таких мелочей, как смена версии MySQL, может больно ударить по работоспособности вашего приложения
```
Хотелось бы побыстрее, но увы и ах. А unbreakable от Oracle на практике оказывается очень даже breakable.
Вообще меня очень поразил Debian. Его добавили как поддерживаемую ОС в архитектуру Power9, что может говорить о том, что скоро начнётся ещё более динамичное развитие этого дистрибутива(ну вот мне так кажется почему-то).
Касательно высказывания
```
Я думаю, что таких компаний, как Red Hat, будет больше, но подобная постановка вопроса сужает рамки такого понятия, как успех с использованием ПО с открытым кодом, – говорит Землин
```
— Дада, конечно, а затем их купит RedHat.
Касательно обучения хотелось бы сказать, что цены очень большие(ну да, не больше чем обучение AIX, IBM i, но всё же). Подписка ROL конских денег стоит и лабы и экзамены очень косячные своей неоднозначностью. Конкретно сейчас меня больше всего «злит» openstack — экзамен 4 часа из которых 3 занимает деплой самого опенстека(хотя по идее должен занимать 40 минут)
Вообще говоря, эта цена на поддержку апдейтов (99 кажется была) мало кого
из клиентов оракла интересует. Сейчас апдейты идут вообще бесплатно. Компании, которые много покупают у Оракла вообще подписывают один рамочный контракт. Скажем, мы платим сколько-то миллионов в год и ставим сколько хотим ODB и кучу других продуктов, включая OL.
Плюсы свай — быстрый монтаж. Фактически, вы уже через день получаете готовый фундамент и можете на нем строить.
С бетонным такая штука не пройдет. Минимум месяц.
Еще один плюс — отсутвтсие подготовительных работ на участке. Просто приезжает трактор и вкручивает, а свай потом подрезаются по нужной высоте. И ничего никто не разравнивает.
Самый жирный минус — отсутствие погреба и хозяйственного помещения под домом. Но если проект этого не предусматривает — сваи являются отличным решением.
В случае с Convention over Configuration, описанном в этой статье, DI-container все еще присутствует, он никуда не делся. Просто объекты в нем регистрируются автоматически, а не вручную.
Так что говорить, что DI-container это ненужный промежуточный шаг — некорректно.
Вот есть небольшая статья на эту тему:
blog.ploeh.dk/2012/11/06/WhentouseaDIContainer
Контейнер остаётся контейнером. В качестве зависимости в отдельных компонентах он пробрасывается, чтобы частично решить проблему переноса зависимости. Скажем, модулю на 3-м уровне нужно 9 зависимостей. Проще пробросить контейнер, чем эти 9 зависимостей тащить из контейнера от точки входа.
Да, сценарий использования похож на типичное использование сервис локатора со стороны зависимого модуля, но решение другое, сервис локатор не управляет жизненным циклом сервисов в общем случае, сервисы регистрируются в нём сами или их регистрируют их создатели, контейнер же создаёт их имея какое-то описание как создавать.
А как код проекта может не зависеть от DI-контейнера я вообще не представляю. Вернее представляю, но только в случае широкого использования метапрограммирования, заменяющего, например, new UserManager на вызов Container::getInstance().get('UserManager'). Как-то нам нужно получать из контейнера то, что мы хотим хотя бы на уровне точки входа в приложение, если пробрасывание десятков зависимостей нас не страшит.
Возможность запросить подключение к БД из слоя представления говорит о том, что Вы и без контейнера сможете создать его вручную, если действительно захотите.
Но, например, в c# если подключение к БД и слой представления разнести по разным проектам, то можно ограничить область видимости и без хаков в виде рефлексии Вы на слое представления не сможете получить БД вообще никак
Например, если в коде есть несколько слоев, то можно легко их и непринужденно нарушать.
Для больших проектов, есть резонный повод использовать готовую реализацию, а вот для библиотек контейнер вреден, на мой взгляд, у тебя возникнет протест, когда у тебя в проекте есть уже одна библиотека, которая реализует контейнер, а в зависимостях другая
Допустим, мы выбрали контейнер. И даже то, что мы получим зависимость от контейнера, будет плюсом. Даже двумя (как минимум). Мы получим: 1) единый «центр управления» — контейнер упростит создание экземпляров и их внедрение (это очевидное преимущество), 2) мы будем использовать «хорошую» зависимость.
Под «хорошей» зависимостью я в данном случае понимаю то, что контейнер поставляется в виде внешней библиотеки. Код контейнера, очень вероятно, будет построен по принципам открытого ПО. Это точно верно для всех контейнеров, упомянутых в статье. Это значит, что этот код будет доступен и многократно перепроверен сообществом.
А я всю жизнь думал, что инкапсуляция, наследование и полиморфизм :) Внедрение зависимостей появилось (читать: начало активно использоваться) гораздо позже, по причине, неплохо описанной в данной статье. Взять тот же Turbo Vision — там даже интерфейсы не использовались (они появились позже), и тем не менее Turbo Vision — это ООП. Кстати, «Внедрение зависимостей», вероятно, стоило бы называть «внедрение независимостей», это лучше отражает суть.
С другой стороны, если посмотреть когда и зачем вообще создавалось такое понятие как дистрибутив, — будет ясно, что дело-то совершенно непростое. Как уже было описано выше
```
Буквально все, от новой версии glibc и вплоть до таких мелочей, как смена версии MySQL, может больно ударить по работоспособности вашего приложения
```
Хотелось бы побыстрее, но увы и ах. А unbreakable от Oracle на практике оказывается очень даже breakable.
Вообще меня очень поразил Debian. Его добавили как поддерживаемую ОС в архитектуру Power9, что может говорить о том, что скоро начнётся ещё более динамичное развитие этого дистрибутива(ну вот мне так кажется почему-то).
Касательно высказывания
```
Я думаю, что таких компаний, как Red Hat, будет больше, но подобная постановка вопроса сужает рамки такого понятия, как успех с использованием ПО с открытым кодом, – говорит Землин
```
— Дада, конечно, а затем их купит RedHat.
Касательно обучения хотелось бы сказать, что цены очень большие(ну да, не больше чем обучение AIX, IBM i, но всё же). Подписка ROL конских денег стоит и лабы и экзамены очень косячные своей неоднозначностью. Конкретно сейчас меня больше всего «злит» openstack — экзамен 4 часа из которых 3 занимает деплой самого опенстека(хотя по идее должен занимать 40 минут)
из клиентов оракла интересует. Сейчас апдейты идут вообще бесплатно. Компании, которые много покупают у Оракла вообще подписывают один рамочный контракт. Скажем, мы платим сколько-то миллионов в год и ставим сколько хотим ODB и кучу других продуктов, включая OL.