Так-же как AcriveRecord делает тривиальными вполне себе сложные
запросы. Он делает простыми запросы на которые приходится 90% всех
случаев использования и прямой доступ к драйверу если нужно что-то
специфичное.
Так-же и тут, большая часть всех зависимостей сводится к таким вещам
как: загрузить зависимости, загрузить код, загрузить конфиг, собрать и
связать с другим приложением. Micon разрешает такие случаи
автоматически.
> > полностью избавится от конфигов в коде
> Зачем?
> > - полностью избавится от 'require' и вообще какого-либо упоминания
> > зависимостей в виде путей и файлов
> Зачем?
Зачем делают рефакторинг и удаление ненужного и лишнего кода? Чтобы
упростить систему.
> > просто перегружать любые значения конфигурации любых компонентов в различных вариантах сборки и енвайронментах
> Зачем?
чтобы приложение можно было строить в виде многократно используемых
модулей, которые просто настраивать в различном окружении: blog/forum/
cms
а не в виде одной папки app/controllers/* где находится много-много
десятков контроллеров.
> > - разделить приложение на части которые ничего не знают друг о друге
> > кроме имени и нескольких публичных методов
> Не будет такого в реальной жизни. Зависимости проникают между всеми
> слоями приложения.
Скажем так, этого почти не бывает в рельсах, точнее я не видел, (хотя
в последних версиях с енджинами вроде что-то сделать можно, кстати
нисколько их не критикую за это и не считаю это их минусом, они
оптимизированы для другого), но это не значит что такого не бывает
вообще. Фактически вы утверждаете что создание слабо-связанных систем
в реальной жизни не возможно, я с этим не согласен - не все можно
изолировать, но некоторые вещи можно.
> > - автоматически собирать компоненты для тестов и обеспечить изоляцию
> > между тестами (восстановение состояния после теста)
> Уже сделано. См test/unit или rspec
Нет, не сделано, если мне нужно протестировать только роутер или
контроллеры в отдельности от всего остального - rspec за меня не
выдернет их из приложения и не сделает так чтобы они заработали без
всего остального.
И если я в процессе тестов нарушу в роутере и контроллере всю
конфигурацию и умолчания - он опять-же ничего за меня не восстановит
как было до теста.
> и более непонятного связывания компонент.
наоборот, когда все модули системы инициилизируются по одному и тому-
же сценарию - все становится проще, знаешь куда идти и где искать, чем
когда каждый модуль имеет свой собственную уникальную инициализацию.
> Откуда такая уверенность, что динамическое связывание компонент -- это хорошо?
> Ведь ребенку понятно, что код вида object->setWidth() более понятен,
> чем object->invoke("setWidth", ...), потому как
> это постоянно заканчивается object->invoke(method, args) и становится
> совершенно непонятно, куда дальше
> уйдет управление.
это как посмотреть, когда этот object->invoke('setWidth', ...) всего в
одном экземпляре, а конструкций типа object->setXxx() сотни
разбросанных по всей системе - то что это спорный вопрос что проще.
П.С.
кстати, если вам что-то показалось непонятным или странным в
документации - дайте знать пожалуйста,
--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
Комментариев нет:
Отправить комментарий