Комментарии 5
Надеюсь это просто опечатка — нижележащие слои должны быть зависимы на более высокоуровневых слоях. Смысл подобного разделения на слои не только в повторном использовании, но ещё и в локализации влияния изменений (и тестируемости, как вы и сказали). Изменения в низкоуровневый код не должны приводить к изменениям в высокоуровневом коде — бизнес логике, сущностях и юзкейсах. Горизонтальное разделение архитектуры — это так же и способ организации процесса командной разработки. Повторно использовать, как правило, приходится только высокоуровневый код, именно для его изоляции и существует слоистая архитектура. Игнорирование этого принципа приводит к монолитному коду и всем вытекающим последствиям. Я не могу похвастаться таким большим опытом как у вас, но за свою скромную карьеру мне приходилось не раз повторно использовать существующую бизнес логику.
Думаю да, опечатка, я вроде аккуратно переводил. Возможно, для автора английский не совсем прям, как родной.
Два момента:
- Опыт, который упоминается в статье — это опыт не мой, а автора. Но, ссылаясь на лично свой, то для примера выделение слоев абстракций для работы с БД, файловыми системами помогло мне лишь однажды из 10+ проектов. Так что да — в моем случае это была лишняя работа. Особенно это касается работы с Android приложениями, где локально
sqliteвообще безальтернативна. - На самом деле эта статься интересна, как стартовая для описания dart-библиотеки rx_command, и после утомительного boilerplate
InheritedWidgets&BLoCдля меня это действительно находка. Вот, на днях переведу остальное.
Если у вас есть универсальный код, который можно переиспользовать, имеет гораздо больше смысла собрать его в некую универсальную же библиотеку;
А эта библиотека что, уже как бы и не слой?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RxVMS — практичная архитектура для Flutter-приложений