Thiết kế web đáp ứng có đi ngược lại nguyên tắc Tách biệt các mối quan tâm không?


8

Tôi đang tự hỏi làm thế nào thiết kế đáp ứng hoạt động cùng với nguyên tắc Tách biệt mối quan tâm, liên quan đến cách chúng tôi cho phép một triển khai duy nhất hoạt động cho nhiều thiết bị trình bày (di động, máy tính bảng, kích thước trình duyệt, v.v.). Là nó phá vỡ nguyên tắc?

Nếu tôi thực hiện thay đổi cho một trang web mà tôi biết đang hoạt động nhạy bén và nên hoạt động trên 5 thiết bị chẳng hạn, tôi có làm cho việc phát triển trở nên cực kỳ khó khăn do hồi quy có thể xảy ra từ một vị trí duy nhất trong phần mềm không?

Chắc chắn rằng điều đó khiến tôi viết ít mã hơn và hoạt động nhanh hơn trên nhiều thiết bị, nhưng bây giờ mỗi trang của tôi yêu cầu thử nghiệm kỹ lưỡng hơn nhiều, đó là chi phí tôi có thể chuyển sang không sử dụng khung web đáp ứng và duy trì triển khai riêng biệt trang.


Bạn đang hỏi về mặt thiết kế đáp ứng cho UI?
DFord

1
Đúng. Thiết kế UI đáp ứng với các khung như Boiler khắc, Bootstrap, v.v.
Martin Blore

1
đó chỉ là vi phạm SoC / SRP nếu khả năng phản hồi được xử lý bởi nhiều hơn một lớp / thành phần
Steven A. Lowe

Câu trả lời:


3

Làm thế nào bạn hiện đang xem xét phản ứng đi ngược lại nguyên tắc phân tách mối quan tâm. Câu hỏi của bạn cho rằng khả năng đáp ứng là một trách nhiệm duy nhất chỉ thuộc về một thành phần.

Tôi muốn đề xuất rằng tính đáp ứng là một thuộc tính / trách nhiệm có thể được áp dụng cho nhiều thành phần. Vì lợi ích của ví dụ của tôi, tôi giả sử một MVC chung | MVP | Mẫu kiểu MVVM.

Các Xem chắc chắn nhất có một bàn tay trong phản hồi của ứng dụng. Các thành phần UI và logic mà bạn sử dụng tất cả chỉ ra cách thức Chế độ xem sẽ thực hiện. Vì vậy, View chịu trách nhiệm về tính đáp ứng của các thành phần UI.

Bộ điều khiển cũng có khả năng đáp ứng ứng dụng. Các loại cấu trúc dữ liệu và cách logic kinh doanh được tạo ra sẽ ảnh hưởng đến hiệu suất. Vì vậy, ở đây, Bộ điều khiển | Người trình bày | ViewModel cũng có trách nhiệm đáp ứng. Nhưng trách nhiệm này thuộc về các yếu tố khác với những gì mà View chịu trách nhiệm.

Cuối cùng, Model chịu trách nhiệm cho các cuộc gọi dịch vụ / truy cập dữ liệu. Có những cân nhắc hiệu suất rõ ràng trong cách dữ liệu được lấy và trình bày cho lớp giữa. Nhưng một lần nữa, đây là một yếu tố khác nhau cũng phải được đáp ứng.

Responsivenessnhư một tài sản không phải là trách nhiệm duy nhất của bất kỳ một thành phần nào. Tất cả các thành phần phải chịu trách nhiệm cho việc chế tạo riêng của chúng để đóng góp vào ứng dụng tổng thể. Một UI và Trình điều khiển tuyệt vời có thể được hiển thị vô dụng bằng các yêu cầu dữ liệu dường như vô tận.

Theo như thử nghiệm, sử dụng cách tiếp cận theo cấp bậc vẫn có lợi cho bạn về nỗ lực và khả năng đáp ứng tổng thể. Nếu bạn có 5 thiết bị và viết các lớp riêng lẻ cho mỗi thiết bị, bạn sẽ có 15 thành phần để kiểm tra. Sử dụng mẫu MVC * cho phép bạn loại bỏ 8 thành phần khỏi kiểm tra do bạn có Mô hình và Trình điều khiển chung. Nếu hai lớp đó thực hiện phần công việc của chúng trong việc phản hồi, thì bạn chỉ phải kiểm tra chúng một lần. Sau đó, bạn có thể tập trung nỗ lực còn lại của mình vào 5 Lượt xem.


Cảm ơn vì câu trả lời này Glen. Tôi thậm chí đã không xem Thiết kế đáp ứng ngoài những gì tôi nghĩ chỉ là khung giao diện người dùng web.
Martin Blore

2

Tôi không nghĩ rằng nó vi phạm sự phân tách mối quan tâm vì CSS sử dụng các truy vấn phương tiện để phân tách kiểu cho một kích thước màn hình cụ thể. Các truy vấn phương tiện đóng gói mã cho một kích thước màn hình cụ thể.

Tôi nghĩ, thay vì nghĩ về thiết kế đáp ứng như làm việc cho số lượng thiết bị X, thiết kế đáp ứng nên được coi là hoạt động cho tất cả các kích thước màn hình. Đó là cùng một trang web, chỉ cần theo kiểu kích thước màn hình.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.