Это вредный совет. У нас например общая доменная база мобильного приложения и веб сайта/апи. Если последовать вашему совету, то все грустно получается.
Хм, у меня другая информация. Эти отделы конечно можно развить, но никак не преодолеть такой перевес. Но все же я не ученый в этой области, так что утверждать не буду.
Мы явно не понимаем друг друга ;(. Ни о каких God-object'ах не идет речи. Я не готов писать развернутый ответ, так как для этого потребуется написать книгу. Например https://habrahabr.ru/company/piter/blog/192348/
Вы про то, как например в Java сделана BufferedStream? Что же в нем такого уж дурно пахнущего? Опять же если вы кэш делаете, то видимо и инвалидацию — она у вас ведь не по таймауту?
Инвалидацией занимается тотже декоратор. Дурной запах в том, что при добавлении кеша сервис начинает выполнять две задачи: свою работу и заботу о кеше.
А можете поподробнее? Как это вы так структурируете код, что добавление зависимости требует что-то шерстить?
Например сервису «карты» понадобилось отправлять сообщения пользователям при каких-то событиях. Если мы используем ДИ, то мы просто добавляем в конструктор параметр IMessageCenter. А если мы используем new, то надо искать везде этот new и добавлять туда новый параметр, к тому же надо что бы вызывающий метод имел доступ к IMessageCenter(И он например создается один на webrequest).
А как обстоят дела с наследованием и несколькими реализациями интерфейса? Вы же эти правила прописываете в кофигурации контейнера? А значит вам придется кропотливо следить за тем в каком случае кто и как решил отрезолвить интерфейс (в одном случае нам тот же кэш нужен, а в другом нет или другой кэш). Конфигурация видимо инициализируется на запуске приложения (привет многопоточность), либо на запуске каждого инстанса (привет производительность).
Да, все это настраивается в композиции. В ОДНОМ месте. А не разбросаны по всему коду. Что насчет производительности, то это почти никогда не вызывает проблем, а если вам выпал шанс один на миллиард, то с этим можно справится(Я не могу придумать ситуации где это будет сделать трудно)
Ага, а потом попробуйте добавить например кеш на какой-нибудь сервис. И в итоге ваш сервис будет заботится о своей непосредственной работе, а так же о кеше. Это явно дурно пахнущий код.
С Ди это решается на раз с помощью декоратора или даже перехвата. А если же вы захотите использовать декоратор, то вам придется проштудировать весь исходный код в поисках new. Так же вам нужно будет шерстить весь код, если классу понадобилась новая зависимость. Кстати, эту зависимость еще надо пробросить до сервиса. А как обстоят дела с временем жизни зависимостей? При new вам придется кропотливо за всем следить и управлять этим руками.
В том и дело, что если использовать сервис локатор правильно, то он будет неотличим от контейнера(Не будет зависимостей от локатора). В свою очередь практически все контейнеры позволяют использовать себя как сервис локаторы.
Кстати, я так и не нашел решения как обходится без сервис локатора(Резолва вне композиции объектов), когда нужны фабрики и отсутствует возможность автоматической генерации.
Регистрировать Func и т.п. мне кажется крайне уродливым.
Эм… проблема в архитектуре движка решается дичайшим костылем? Или я что-то путаю?
Даже в битриксе компоненты подключают свои css и js только когда используются :)
Главный для меня вопрос, получается я смогу писать код для браузера на c#? И разор будет работать на клиенте? да целый asp.net получается можно вытащить на клиента, а сервер будет RESP api например + отдача загрузчика
Можно узнать хоть одну причину делать текст в две колонки. Ведь это читать неудобно, приходится зумить колонку, но тогда строчки маленькие :( Или это сделано специально, что бы читали не пдф, а с вашего сайта?
Инвалидацией занимается тотже декоратор. Дурной запах в том, что при добавлении кеша сервис начинает выполнять две задачи: свою работу и заботу о кеше.
Например сервису «карты» понадобилось отправлять сообщения пользователям при каких-то событиях. Если мы используем ДИ, то мы просто добавляем в конструктор параметр IMessageCenter. А если мы используем new, то надо искать везде этот new и добавлять туда новый параметр, к тому же надо что бы вызывающий метод имел доступ к IMessageCenter(И он например создается один на webrequest).
Да, все это настраивается в композиции. В ОДНОМ месте. А не разбросаны по всему коду. Что насчет производительности, то это почти никогда не вызывает проблем, а если вам выпал шанс один на миллиард, то с этим можно справится(Я не могу придумать ситуации где это будет сделать трудно)
С Ди это решается на раз с помощью декоратора или даже перехвата. А если же вы захотите использовать декоратор, то вам придется проштудировать весь исходный код в поисках new. Так же вам нужно будет шерстить весь код, если классу понадобилась новая зависимость. Кстати, эту зависимость еще надо пробросить до сервиса. А как обстоят дела с временем жизни зависимостей? При new вам придется кропотливо за всем следить и управлять этим руками.
Кстати, я так и не нашел решения как обходится без сервис локатора(Резолва вне композиции объектов), когда нужны фабрики и отсутствует возможность автоматической генерации.
Регистрировать Func и т.п. мне кажется крайне уродливым.
Даже в битриксе компоненты подключают свои css и js только когда используются :)
За перевод спасибо