レスポンシブWebデザインは、懸念分離の原則に反していますか？

複数のプレゼンテーションデバイス（モバイル、タブレット、ブラウザーのサイズなど）に対して単一の実装をどのように動作させるかについて、関心の分離の原則と共にレスポンシブデザインがどのように機能するのかと思います。それは原則を破っていますか？

たとえば、応答が速く、5つのデバイスで動作するはずであることがわかっているWebページに変更を加えた場合、ソフトウェアの1か所から発生する可能性のある回帰により、開発を極端に難しくしていませんか？

確かに、コードの作成が少なくなり、複数のデバイスではるかに高速に動作するようになりましたが、今では、ページごとに徹底的なテストが必要になる可能性があります。これは、レスポンシブWebフレームワークを使用せず、ページ。

現在の応答性の見方は、懸念の分離の原則に反しています。あなたの質問は、応答性が1つのコンポーネントにのみ属する単一の責任であると想定しています。

応答性は、複数のコンポーネントに適用できる属性/責任であることをお勧めします。私の例では、一般的なMVCを想定しています。MVP | MVVMタイプパターン。

ビューは最も確かにアプリケーションの応答性に手を持っています。すべて使用するUI要素とロジックによって、ビューの実行方法が決まります。そのため、ビューはUI要素の応答性に責任があります。

コントローラは、アプリケーションの応答性の手を持っています。データ構造のタイプとビジネスロジックの作成方法がパフォーマンスに影響します。ここで、コントローラー| プレゼンター| ViewModelは応答性にも責任があります。ただし、この責任は、ビューが担当する要素とは異なる要素に対するものです。

最後に、モデルはデータアクセス/サービス呼び出しを担当します。データがどのように取得されて中間層に提示されるかについては、明らかなパフォーマンス上の考慮事項があります。しかし、繰り返しになりますが、これも応答が必要な別の要素です。

Responsivenessプロパティは、1つのコンポーネントの単一の責任ではありません。すべてのコンポーネントは、全体的なアプリケーションに貢献するために、独自の細工を担当する必要があります。優れたUIとコントローラーは、一見すると果てしないデータリクエストによって、役に立たなくなる可能性があります。

テストに関しては、階層化されたアプローチを使用しても、全体的な作業と応答性に関して有利に機能します。5つのデバイスがあり、各デバイスに個別のレイヤーを書き込んだ場合、テストするコンポーネントは15になります。MVC *パターンを使用すると、共通のモデルとコントローラーがあるため、8つのコンポーネントをテストから削除できます。これらの2つのレイヤーがレスポンシブで作業を分担している場合は、一度テストするだけで済みます。その後、残りの作業を5つのビューに集中できます。

CSSはメディアクエリを使用して特定の画面サイズのスタイルを分離するため、問題の分離に違反しているとは思いません。メディアクエリは、特定の画面サイズのコードをカプセル化します。

レスポンシブデザインはX台のデバイスで機能するものと考えるのではなく、すべての画面サイズで機能するものと考える必要があります。画面サイズに合わせた同じWebページです。