Я знаю что у меня в vscode линтер притекает, и в какой-то момент он может отжирать вообще всю свободную память, после чего приходится перезапускать сервер eslint. Возможно и другие плагины могут себя похожим образом вести. Короче проблемы есть. На скрине же я просто открывал файлы, без работы с ними, и каких-то просадок по общему потреблению памяти не увидел. Да и даже то что на скрине, могло легко гулять +/-50 мб, в результате каких-то внутренних изменений.
На протяжении многих лет наблюдаю, как много людей остаются недовольными изменениями в интерфейсе Windows. Или на днях обновил операционку на маке, после того как несколько месяцев не включал его, и обнаружил что там полностью поменяли приложение настроек. Думаю это тоже вызвало недовольство многих пользователей. Хотя как по мне - стало лучше.
В общем, гайдлайны той или иной ОС меняются довольно часто. И их авторам приходится учитывать паттерны, к которым привыкают люди на других платформах, адаптироваться к новым технологиям, исследованиям и всё прочее. То есть внезапно оказывается, что гайдлайны являются стандартом только в рамках определенной версии ОС, и могут меняться раз в несколько лет даже в рамках одной операционной системы на одной платформе. В итоге далеко не для всех, гайдлайны ОС могут быть удобным ориентиром, по разным причинам. В том числе и по причине возникающих в них изменений, которые необходимо поддерживать и согласовывать в разных окружениях. И по этому yet another neskuchnaya button, может оказаться не хитрой выдумкой дизайнера или проектировщика, а вполне себе требование бизнеса, вычисляемое в деньгах.
У меня vs code из-под WSL запушен, так что там есть серверный процесс и клиентский. Думаю можно их вместе считать. За время открытия файлов память не существенно выросла, открыл около 500. Итого чуть больше 800 мб
не разбираться с очередным высером на джаваскрипте с нескучными эффектами и transition- переходами между шагами
Плавные переходы могут иметь логичную природу. Например чтобы изменения в интерактивном интерфейсе, казались пользователю последовательными и обратимыми. Также плавные переходы позволяют маскировать различные вычисления, например клиент-серверные взаимодействия, чтобы интерфейс не казался зависающим и прыгающим.
Пользователь хочет СТАНДАРТНЫЙ интерфейс
Можно попробовать даунгрейднуться на перфокарты или что еще примитивнее, уверен что там было меньшее количество ключевых различий интерфейса, чем в куче современных гайдлайнов различных GUI. А если серьезно, то мне не очень понятно что в Вашем понимание означает стандартный интерфейс, и кто или что обеспечивает эту самую стандартизацию. Возможно дело просто в определенных привычках, а не в отсутствии следования тем или иным стандартам. Но выработанная привычка не означает привязку к чему-то стандартному или даже просто хорошему, и подходящему для всех. Особенно учитывая как сильно изменились цифровые устройства и способы взаимодействия с ними за относительно небольшой промежуток времени. То есть элементарно: различные поколения, уже взрослых людей, могут иметь совершенно разные представления о том, что для них является преимущественно стандартным интерфейсом и почему.
Впрочем я могу согласиться, что во многих программах могут быть не самые лучшие графические интерфейсы. Но у меня не вызывает это столько эмоций и раздражения в адрес проектировщиков, я скорее с этим не согласен.
По моему опыту, самое полезное, что я сделал в плане понимания работы этих операторов, это просто разобрался с marble diagrams. Потратил несколько минут, а все вопросы просто исчезли сами собой.
Никаких слушаний, на сколько я понял, не было. Так что сложно сказать как с точки зрения закона выглядит этот прецедент. Возможно ничего адаптировать и не требуется.
Может понравится ant. Хотя я не особо представляю какой он под vue, использовал его только с ангуляром, но судя по компонентам в документации, набор вроде плюс минус один и тот же. Про техническую часть и удобство использования не могу судить.
Еще раз, объективная сторона преступления, не может быть виной просто по определению. Вина должна быть сопряжена с осознанием ответственности (косвенной тоже), если осознания нет, то там уже другие механизмы включаются. В данном случае осознание было.
Преступление признается совершенным с косвенным умыслом, если лицо осознавало общественную опасность своих действий (бездействия), предвидело возможность наступления общественно опасных последствий, не желало, но сознательно допускало эти последствия либо относилось к ним безразлично.
Именно в этом и заключается вина в случае запрета использования болгарки
Запрет в данном случае, это всего лишь регуляция. Я не спорю что у нас законодательство может быть не совершенным в плане регуляции ПО. Но подобные статьи и рассуждения, лишь усиливают страх перед попытками наладить легальную деятельность в этой сфере. Потому что люди банально боятся подавать заявки в регулирующие органы, так как обеспокоены тем, что за одну лишь заявку их уже могут закрыть. Вы видимо из таких, но не все думают также.
Нюансы то конечно есть. И я даже не спорю, что это может быть достаточно интересным прецедентом, хотя мне так не кажется.
Дальше будем рассуждать как правоохранители.
Хоть я имею очень слабое представление о том как могут рассуждать правоохранители, но думаю субъективная сторона здесь в том, что человек получал материальную выгоду. И так же осознавал возможность использования своего софта в противоправных целях (для нечестной борьбы с конкурентами), что он подтвердил прямым текстом.
Помимо этого, как я уже говорил, нам об этом деле известно только со слов обвиняемого, и то что он заостряет внимание на отдельной утилите, я не думаю что это вся суть дела. Даже эксперт Хабра, сразу же отметил важность именно связки сканнера arachni и sqlmap. Предположу, что и в экспертизе представленной суду, это тоже было отмечено. То есть в экспертизе скорей всего была представлена какая-то довольно однозначная классификация данного программного комплекса, в большей степени основанная на предполагаемых способах его применения. А флаги и тд, должны были отобразить компетентность автора в этих вопросах. Но тут без бумаг можно спекулировать бесконечно. Только экспертиза это еще не обвинение, а просто демонстрация того, что именно мог осознавать обвиняемый, выставляя свой продукт на продажу, помимо того, что он подтвердил своими словами.
Если вы сможете предложить варианты, как использовать болгарку для срезания двери без желания на то и без выполнения действий по использованию болгарки для этого - попробуйте изложить.
Например пожарные, или опять же правоохранители могут срезать двери болгарками по долгу службы, и это не будет преступлением. Думаю и еще множество вариантов можно придумать.
болгарка не моя, я случайно кнопку нажал и она срезала дверь
Обвиняемый по сути примерно так и аргументирует свою позицию, и вы сами понимаете на сколько это слабая аргументация.
Собственно да, нет состава преступления - нет дела. Это УПК и регулирует. Строго определение состава преступления на сколько я знаю в российском законодательстве нет, но как вы и отметили в него входят несколько ключевых составляющих. Состав преступления используется в УПК, и пункт 2 статьи 24 УПК обязателен к исполнению.
Объективная сторона преступления, не может одновременно являться и субъективной. В итоге, вы сами указываете на то что одного лишь факта создания/использования не достаточно для признания этого действия преступным, и следовательно недостаточно для какого-либо обвинения. Но при этом продолжаете утверждать, что "преступление - само использование болгарки".
Про закрытие глаз, это как раз тогда и выходит, что статью можно применять к чему угодно. Но это не так. Статьи УК применимы только к преступлениям. УК - это грубо говоря система ссылок: действие - ответственность. Действие само по себе не является преступлением. Заведомость, умысел и прочие аспекты состава преступления регулируются уголовно-процессуальными нормами, там же определяется чем является преступление, и чем не является.
Про "risk=3 и level=5", по моему мнению, хоть я и не юрист, это больше похоже на линию защиты. Из экспертизы берется неоднозначное утверждение, и на этом основании демонстрируется несостоятельность всей экспертной оценки. Просто про флаги мы знаем только со слов обвиняемого, а не из экспертизы. Возможно в самой экспертизе там этим флагам уделена одна строчка из всего многостраничного документа.
Мне кажется, здесь есть некоторая проблема с определением того что считать более безопасным. Вы определяете это через соотношение взломанных систем к невзломанным. Для кого-то может быть важным количество патчей с закрытием уязвимостей за определенное время, для кого-то отсутствие таких патчей и тд. В общем тут много всего можно намерить, в зависимости от преследуемых целей. Но обычно уровень безопасности определяется комплексом применяемых мер, то есть как минимум -- это процесс. Что уже делает сравнение уровня безопасности двух операционных систем довольно бессмысленным.
Я лишь хотел отметить, что предложенное соотношение, может в большей степени свидетельствовать об уровне интереса разработчиков специализированного софта, чем об уровне безопасности системы как таковом. И возможно о том, что у пользователей линукса в среднем процессы по обеспечению безопасности налажены лучше, чем у пользователей винды, просто в силу лучшей компьютерной грамотности пользователей линукса. Что еще больше должно отбивать интерес у разработчиков вредоносного софта. Но для Вас, возможно, это все одно и тоже, и входит в понятие уровня безопасности линукса, и действительно, тут как посмотреть.
а вы смотрите не на кол-во заражённых а на соотношение заражённых к незаражённым в пределах одной ОС пусть даже только на десктопе
Тут все же сложнее зависимости будут. Зачем изначально ограничиваться лишь парой процентов потенциальных пользователей, когда есть гораздо более распространенная система? Это как и с обычным софтом, под линукс его не адаптируют не потому что это невозможно сделать, а потому что не видят в этом выгоды.
Вы как-то как-то из одной плоскость в другую перескакиваете. Если взять например двух программистов, допустим тех же формошлепов, с сопоставимым по времени и задачам опыту работы (с одного отдела на работе например). При этом один из них без высшего образование, а другой имеет айтишное или математическое. То вы действительно считаете, что при поиске решения вашей задачи, они будут находится в изначально равных условиях, или что у самоучки будет преимущество?
Я не спорю, конечно, что результат подобного эксперимента может оказаться неожиданным, так как не проводил его и не читал про подобные. Но это вполне себе проверяемое утверждение.
Так самые банальные задачки могут быть связаны с этим умножением матриц. Например есть какая-нибудь таблица значений, и есть список коэффициентов для этих значений, необходимо просуммировать значения в каждой строке таблицы с учетом коэффициентов. Первое что на ум приходит, это допустим подсчитать общую стоимость различных услуг для каждого пользователя.
По сути это задача умножения матрицы на вектор, но подобные абстракции в формулировке или решении задачи могут вызывать недоумение у неподготовленных людей. Не то чтобы для примера выше нужны подобные абстракции, эта задача и так легко описывается. Но если источников данных не два, а чуть больше, и расчеты немного сложнее, то использование элементов той или иной теории может оказаться просто удобным инструментом, как для формулирования, так и для реализации задач.
То есть, как минимум, наличие общей теоретической базы может позволить общаться на простом языке, через использование сложных абстракций. Хотя соглашусь, что в большинстве случаев это вовсе необязательно, многие задачи можно и на пальцах объяснить.
Если сервис является зависимостью только для одного lazy модуля, то зачем его создавать на старте приложения
Если я ничего не путаю, то инстанс все же создается по требованию за счет DI, а не на старте приложения. То есть для ленивых модулей, сервис может загружаться так же лениво. Если сервис нигде не используется, он не будет включен в сборку за счет встряхивания дерева.
Ангуляровский подход по умолчанию предполагает, что сервисы являются одиночками, в рамках всего приложения. За счет как раз указания опции providedIn: 'root', вместо прямого прописывания провайдера в соответствующий модуль, становятся доступны все эти средства для оптимального распределения кода по нужным чанкам бандла.
Не корневые сервисы, зачастую поставляются с модулем, который позволяет устанавливать конфигурацию на уровне DI (вот эти все модули с .forRoot, .forChild), что требуется крайне редко.
В общем если нужен просто сервис-одиночка, без всяких хитростей с DI, без множественных инстансов и без жесткого ограничения на конкретный модуль, то предпочтительный вариант - это использовать @Injectable({ providedIn: 'root' }). Кроме того, если необходим новый инстанс сервиса на уровне каких-то конкретных компонентов, то лучше их прокидывать через провайдеры самих компонентов.
Про жесткое ограничение на конкретный модуль, я имел ввиду, что если какой то сервис попадает в тот же самый index.ts в виде экспорта, то лучше чтобы он был корневым. Это гораздо лучше позволит оптимизировать конечный бандл, чем подключение этого сервиса через еще одну прослойку в виде модуля, в котором он прописан.
Как мне кажется, для импортов в рамках приложения, лучше использовать один скоуп: @app-name/auth, @app-name/system и т. д. Как минимум, чтобы можно было визуально понимать, что импорт относится именно к приложению, а не к какой-то библиотеке.
Служебные директории core, при таком подходе, очень легко могут превратится в очень большие свалки в каких-то общих модулях (app, shared и т. д.), но зависит конечно от предполагаемого объема приложения. То есть неглубокая вложенность - это конечно хорошо, но когда приходится работать с сотней подобных сервисов или интерфейсов:
import { TransactionsService, UsersService } from '@app/core/services';
import { TransactionDto, UserDto } from '@app/core/interfaces';
то такая плоская структура не всегда может быть удобной. Хочется иметь какое-то разделение подобных сервисов и интерфейсов на домены, но при этом не сильно увеличивая связность различных модулей. То есть для решения этой проблемы может понадобится введение дополнительных абстракций в структуру приложения, по типу: entities/transactions/transactions.service.ts, entities/transactions/transactions.interface.ts. В таком случае вложенность увеличивается не сильно, но нет такой проблемы, что сначала в одной директории среди большого множества файлов ищешь сервис, а потом в соседней директории, среди такого же множества файлов ищешь интерфейс данных, с которыми работает данный сервис. Иногда же бывает, что помимо сервиса и интерфейса данных, еще имеются какие-нибудь сторы и прочие инструменты, требуемые в рамках работы с одними и теми же данными. Впрочем редакторы сильно упрощают навигацию по коду, но все равно довольно сложно удерживать в голове: какие инструменты доступны для работы с теми же транзакциями, а какие нет. Разделение на основе семантики, а не по функциональному признаку, может значительно упростить восприятие отдельных частей проекта.
Кстати для контроля зависимостей между различными узлами приложения можно использовать NX. Там есть утилиты для линтера, для которых задаются правила: что, откуда и куда может импортироваться. Да и помимо этого, для ангуляра там достаточно удобный туллинг, именно в плане организации структуры репозитория.
Я знаю что у меня в vscode линтер притекает, и в какой-то момент он может отжирать вообще всю свободную память, после чего приходится перезапускать сервер eslint. Возможно и другие плагины могут себя похожим образом вести. Короче проблемы есть. На скрине же я просто открывал файлы, без работы с ними, и каких-то просадок по общему потреблению памяти не увидел. Да и даже то что на скрине, могло легко гулять +/-50 мб, в результате каких-то внутренних изменений.
На протяжении многих лет наблюдаю, как много людей остаются недовольными изменениями в интерфейсе Windows. Или на днях обновил операционку на маке, после того как несколько месяцев не включал его, и обнаружил что там полностью поменяли приложение настроек. Думаю это тоже вызвало недовольство многих пользователей. Хотя как по мне - стало лучше.
В общем, гайдлайны той или иной ОС меняются довольно часто. И их авторам приходится учитывать паттерны, к которым привыкают люди на других платформах, адаптироваться к новым технологиям, исследованиям и всё прочее. То есть внезапно оказывается, что гайдлайны являются стандартом только в рамках определенной версии ОС, и могут меняться раз в несколько лет даже в рамках одной операционной системы на одной платформе. В итоге далеко не для всех, гайдлайны ОС могут быть удобным ориентиром, по разным причинам. В том числе и по причине возникающих в них изменений, которые необходимо поддерживать и согласовывать в разных окружениях. И по этому yet another neskuchnaya button, может оказаться не хитрой выдумкой дизайнера или проектировщика, а вполне себе требование бизнеса, вычисляемое в деньгах.
У меня vs code из-под WSL запушен, так что там есть серверный процесс и клиентский. Думаю можно их вместе считать. За время открытия файлов память не существенно выросла, открыл около 500. Итого чуть больше 800 мб
Плавные переходы могут иметь логичную природу. Например чтобы изменения в интерактивном интерфейсе, казались пользователю последовательными и обратимыми. Также плавные переходы позволяют маскировать различные вычисления, например клиент-серверные взаимодействия, чтобы интерфейс не казался зависающим и прыгающим.
Можно попробовать даунгрейднуться на перфокарты или что еще примитивнее, уверен что там было меньшее количество ключевых различий интерфейса, чем в куче современных гайдлайнов различных GUI. А если серьезно, то мне не очень понятно что в Вашем понимание означает стандартный интерфейс, и кто или что обеспечивает эту самую стандартизацию. Возможно дело просто в определенных привычках, а не в отсутствии следования тем или иным стандартам. Но выработанная привычка не означает привязку к чему-то стандартному или даже просто хорошему, и подходящему для всех. Особенно учитывая как сильно изменились цифровые устройства и способы взаимодействия с ними за относительно небольшой промежуток времени. То есть элементарно: различные поколения, уже взрослых людей, могут иметь совершенно разные представления о том, что для них является преимущественно стандартным интерфейсом и почему.
Впрочем я могу согласиться, что во многих программах могут быть не самые лучшие графические интерфейсы. Но у меня не вызывает это столько эмоций и раздражения в адрес проектировщиков, я скорее с этим не согласен.
По моему опыту, самое полезное, что я сделал в плане понимания работы этих операторов, это просто разобрался с marble diagrams. Потратил несколько минут, а все вопросы просто исчезли сами собой.
Никаких слушаний, на сколько я понял, не было. Так что сложно сказать как с точки зрения закона выглядит этот прецедент. Возможно ничего адаптировать и не требуется.
Может понравится ant. Хотя я не особо представляю какой он под vue, использовал его только с ангуляром, но судя по компонентам в документации, набор вроде плюс минус один и тот же. Про техническую часть и удобство использования не могу судить.
Еще раз, объективная сторона преступления, не может быть виной просто по определению. Вина должна быть сопряжена с осознанием ответственности (косвенной тоже), если осознания нет, то там уже другие механизмы включаются. В данном случае осознание было.
http://www.consultant.ru/document/cons_doc_LAW_10699/4e64d39e2ce45fc366ecd1a304c2ac6fdf0a098a/
Статья 25.
Запрет в данном случае, это всего лишь регуляция. Я не спорю что у нас законодательство может быть не совершенным в плане регуляции ПО. Но подобные статьи и рассуждения, лишь усиливают страх перед попытками наладить легальную деятельность в этой сфере. Потому что люди банально боятся подавать заявки в регулирующие органы, так как обеспокоены тем, что за одну лишь заявку их уже могут закрыть. Вы видимо из таких, но не все думают также.
Нюансы то конечно есть. И я даже не спорю, что это может быть достаточно интересным прецедентом, хотя мне так не кажется.
Хоть я имею очень слабое представление о том как могут рассуждать правоохранители, но думаю субъективная сторона здесь в том, что человек получал материальную выгоду. И так же осознавал возможность использования своего софта в противоправных целях (для нечестной борьбы с конкурентами), что он подтвердил прямым текстом.
Помимо этого, как я уже говорил, нам об этом деле известно только со слов обвиняемого, и то что он заостряет внимание на отдельной утилите, я не думаю что это вся суть дела. Даже эксперт Хабра, сразу же отметил важность именно связки сканнера arachni и sqlmap. Предположу, что и в экспертизе представленной суду, это тоже было отмечено. То есть в экспертизе скорей всего была представлена какая-то довольно однозначная классификация данного программного комплекса, в большей степени основанная на предполагаемых способах его применения. А флаги и тд, должны были отобразить компетентность автора в этих вопросах. Но тут без бумаг можно спекулировать бесконечно. Только экспертиза это еще не обвинение, а просто демонстрация того, что именно мог осознавать обвиняемый, выставляя свой продукт на продажу, помимо того, что он подтвердил своими словами.
Например пожарные, или опять же правоохранители могут срезать двери болгарками по долгу службы, и это не будет преступлением. Думаю и еще множество вариантов можно придумать.
Обвиняемый по сути примерно так и аргументирует свою позицию, и вы сами понимаете на сколько это слабая аргументация.
Собственно да, нет состава преступления - нет дела. Это УПК и регулирует. Строго определение состава преступления на сколько я знаю в российском законодательстве нет, но как вы и отметили в него входят несколько ключевых составляющих. Состав преступления используется в УПК, и пункт 2 статьи 24 УПК обязателен к исполнению.
Объективная сторона преступления, не может одновременно являться и субъективной. В итоге, вы сами указываете на то что одного лишь факта создания/использования не достаточно для признания этого действия преступным, и следовательно недостаточно для какого-либо обвинения. Но при этом продолжаете утверждать, что "преступление - само использование болгарки".
Про закрытие глаз, это как раз тогда и выходит, что статью можно применять к чему угодно. Но это не так. Статьи УК применимы только к преступлениям. УК - это грубо говоря система ссылок: действие - ответственность. Действие само по себе не является преступлением. Заведомость, умысел и прочие аспекты состава преступления регулируются уголовно-процессуальными нормами, там же определяется чем является преступление, и чем не является.
Про "risk=3 и level=5", по моему мнению, хоть я и не юрист, это больше похоже на линию защиты. Из экспертизы берется неоднозначное утверждение, и на этом основании демонстрируется несостоятельность всей экспертной оценки. Просто про флаги мы знаем только со слов обвиняемого, а не из экспертизы. Возможно в самой экспертизе там этим флагам уделена одна строчка из всего многостраничного документа.
Уголовным кодексом не регулируется состав преступления. Это регулируется уголовно-процессуальным кодексом.
Мне кажется, здесь есть некоторая проблема с определением того что считать более безопасным. Вы определяете это через соотношение взломанных систем к невзломанным. Для кого-то может быть важным количество патчей с закрытием уязвимостей за определенное время, для кого-то отсутствие таких патчей и тд. В общем тут много всего можно намерить, в зависимости от преследуемых целей. Но обычно уровень безопасности определяется комплексом применяемых мер, то есть как минимум -- это процесс. Что уже делает сравнение уровня безопасности двух операционных систем довольно бессмысленным.
Я лишь хотел отметить, что предложенное соотношение, может в большей степени свидетельствовать об уровне интереса разработчиков специализированного софта, чем об уровне безопасности системы как таковом. И возможно о том, что у пользователей линукса в среднем процессы по обеспечению безопасности налажены лучше, чем у пользователей винды, просто в силу лучшей компьютерной грамотности пользователей линукса. Что еще больше должно отбивать интерес у разработчиков вредоносного софта. Но для Вас, возможно, это все одно и тоже, и входит в понятие уровня безопасности линукса, и действительно, тут как посмотреть.
Не так давно мигрировал системный диск на nvme от самсунга с помощью https://semiconductor.samsung.com/consumer-storage/support/tools/
Все прошло без проблем. Возможно и от других вендоров подобный софт есть.
Тут все же сложнее зависимости будут. Зачем изначально ограничиваться лишь парой процентов потенциальных пользователей, когда есть гораздо более распространенная система? Это как и с обычным софтом, под линукс его не адаптируют не потому что это невозможно сделать, а потому что не видят в этом выгоды.
Вы как-то как-то из одной плоскость в другую перескакиваете. Если взять например двух программистов, допустим тех же формошлепов, с сопоставимым по времени и задачам опыту работы (с одного отдела на работе например). При этом один из них без высшего образование, а другой имеет айтишное или математическое. То вы действительно считаете, что при поиске решения вашей задачи, они будут находится в изначально равных условиях, или что у самоучки будет преимущество?
Я не спорю, конечно, что результат подобного эксперимента может оказаться неожиданным, так как не проводил его и не читал про подобные. Но это вполне себе проверяемое утверждение.
Так самые банальные задачки могут быть связаны с этим умножением матриц. Например есть какая-нибудь таблица значений, и есть список коэффициентов для этих значений, необходимо просуммировать значения в каждой строке таблицы с учетом коэффициентов. Первое что на ум приходит, это допустим подсчитать общую стоимость различных услуг для каждого пользователя.
По сути это задача умножения матрицы на вектор, но подобные абстракции в формулировке или решении задачи могут вызывать недоумение у неподготовленных людей. Не то чтобы для примера выше нужны подобные абстракции, эта задача и так легко описывается. Но если источников данных не два, а чуть больше, и расчеты немного сложнее, то использование элементов той или иной теории может оказаться просто удобным инструментом, как для формулирования, так и для реализации задач.
То есть, как минимум, наличие общей теоретической базы может позволить общаться на простом языке, через использование сложных абстракций. Хотя соглашусь, что в большинстве случаев это вовсе необязательно, многие задачи можно и на пальцах объяснить.
Думаю, то была отсылка к последствиям первой мировой и подводка к причинам второй.
Если я ничего не путаю, то инстанс все же создается по требованию за счет DI, а не на старте приложения. То есть для ленивых модулей, сервис может загружаться так же лениво. Если сервис нигде не используется, он не будет включен в сборку за счет встряхивания дерева.
Ангуляровский подход по умолчанию предполагает, что сервисы являются одиночками, в рамках всего приложения. За счет как раз указания опции
providedIn: 'root', вместо прямого прописывания провайдера в соответствующий модуль, становятся доступны все эти средства для оптимального распределения кода по нужным чанкам бандла.Не корневые сервисы, зачастую поставляются с модулем, который позволяет устанавливать конфигурацию на уровне DI (вот эти все модули с
.forRoot,.forChild), что требуется крайне редко.В общем если нужен просто сервис-одиночка, без всяких хитростей с DI, без множественных инстансов и без жесткого ограничения на конкретный модуль, то предпочтительный вариант - это использовать
@Injectable({ providedIn: 'root' }). Кроме того, если необходим новый инстанс сервиса на уровне каких-то конкретных компонентов, то лучше их прокидывать через провайдеры самих компонентов.Про жесткое ограничение на конкретный модуль, я имел ввиду, что если какой то сервис попадает в тот же самый
index.tsв виде экспорта, то лучше чтобы он был корневым. Это гораздо лучше позволит оптимизировать конечный бандл, чем подключение этого сервиса через еще одну прослойку в виде модуля, в котором он прописан.Как мне кажется, для импортов в рамках приложения, лучше использовать один скоуп:
@app-name/auth,@app-name/systemи т. д. Как минимум, чтобы можно было визуально понимать, что импорт относится именно к приложению, а не к какой-то библиотеке.Служебные директории core, при таком подходе, очень легко могут превратится в очень большие свалки в каких-то общих модулях (app, shared и т. д.), но зависит конечно от предполагаемого объема приложения. То есть неглубокая вложенность - это конечно хорошо, но когда приходится работать с сотней подобных сервисов или интерфейсов:
то такая плоская структура не всегда может быть удобной. Хочется иметь какое-то разделение подобных сервисов и интерфейсов на домены, но при этом не сильно увеличивая связность различных модулей. То есть для решения этой проблемы может понадобится введение дополнительных абстракций в структуру приложения, по типу:
entities/transactions/transactions.service.ts,entities/transactions/transactions.interface.ts. В таком случае вложенность увеличивается не сильно, но нет такой проблемы, что сначала в одной директории среди большого множества файлов ищешь сервис, а потом в соседней директории, среди такого же множества файлов ищешь интерфейс данных, с которыми работает данный сервис. Иногда же бывает, что помимо сервиса и интерфейса данных, еще имеются какие-нибудь сторы и прочие инструменты, требуемые в рамках работы с одними и теми же данными. Впрочем редакторы сильно упрощают навигацию по коду, но все равно довольно сложно удерживать в голове: какие инструменты доступны для работы с теми же транзакциями, а какие нет. Разделение на основе семантики, а не по функциональному признаку, может значительно упростить восприятие отдельных частей проекта.Кстати для контроля зависимостей между различными узлами приложения можно использовать NX. Там есть утилиты для линтера, для которых задаются правила: что, откуда и куда может импортироваться. Да и помимо этого, для ангуляра там достаточно удобный туллинг, именно в плане организации структуры репозитория.