Пожалуйста, потерпите меня, я не уверен, что смогу еще хорошо сформулировать свой вопрос, поэтому часть проблемы заключается в поиске правильной терминологии / системы отсчета, чтобы задать ее.
Как я понимаюЭто типичный аргумент, который был выдвинут против современной тенденции «компонентного дизайна» в front-end web dev, что он нарушает правило разделения интересов.Рассматриваемое разделение проблем будет заключаться в (семантическом) структурировании документа, его оформлении и добавлении поведения.Но, конечно, мы знаем (сейчас), что на самом деле это не нарушение SOC.Хотя это может «пересечь» эти три «слоя», различие между слоями оказывается не значимым различием для этой ситуации.В самом деле, SOC остается в силе, если мы сократим озабоченность в отношении частей пользовательского интерфейса.По сути, мы изменили фокус с разделения «технологий» (HTML для структуры, CSS для стиля, JS для поведения) на разделение сегментов пользовательского интерфейса, что было бы «перекрестным переходом», если я используютермин правильно.
Итак, давайте теперь рассмотрим эту вторую ситуацию, классическое «разделение работы» между базой данных, внутренним и внешним интерфейсом.Опять же, есть, я бы сказал, прагматичное / реалистическое разделение, основанное на технологиях (и, возможно, также на локальном уровне), между хранением данных (дБ), бизнес-логикой (бэкэнд) и пользовательским интерфейсом (фронт-энд).Но, конечно же, всякий раз, когда я обнаруживаю, что добавляю какую-то часть функциональности в инфраструктуру с этими установленными частями программного обеспечения, например, внутренний (база данных +) и внешний интерфейс, я сталкиваюсь с проблемой, которую вы ожидаете: частьфункциональности требует модификации во всех этих проектах, а для их запуска требуется некоторая оркестровка и т. д. Аналогия с переходом внешнего интерфейса к компонентам совершенно ясна, и было бы очень разумным, если бы существовал что-то вроде «компонента»"что" поперечные разрезы "эти три слоя, а также.Т.е. модульный фрагмент кода, который обрабатывает часть функциональности через эти три уровня: знание, что ему нужна таблица базы данных, знание некоторых бизнес-правил и знание логики пользовательского интерфейса.
ible Является ли то, что я говорю, разумным?
⇨ Если да, есть ли какие-нибудь ключевые / новаторские проекты, где-то где-то пытающиеся выполнить что-то вроде этого?
(Лучший пример, который я могу придумать, - это тенденция универсальной работы JS, ноЯ никогда не видел эту идею зачарованной из соображений выше.)