Làm cách nào tôi có thể tách giao diện người dùng khỏi logic nghiệp vụ mà vẫn duy trì hiệu quả?

Giả sử tôi muốn hiển thị một biểu mẫu đại diện cho 10 đối tượng khác nhau trên hộp tổ hợp. Ví dụ, tôi muốn người dùng chọn một hamburguer từ 10 loại khác nhau có chứa cà chua.

Vì tôi muốn tách giao diện người dùng và logic, tôi phải chuyển biểu mẫu chuỗi của hamburguers để hiển thị chúng trên hộp tổ hợp. Nếu không, UI sẽ phải đào sâu vào các trường đối tượng. Sau đó, người dùng sẽ chọn một hamburguer từ hộp tổ hợp và gửi lại cho bộ điều khiển. Bây giờ bộ điều khiển sẽ phải tìm lại hamburguer dựa trên biểu diễn chuỗi được sử dụng bởi biểu mẫu (có thể là ID?).

Đó không phải là vô cùng hiệu quả? Bạn đã có các đối tượng bạn muốn chọn một trong số đó. Nếu bạn đã gửi biểu mẫu cho toàn bộ các đối tượng và sau đó trả về một đối tượng cụ thể, bạn sẽ không phải từ chối nó sau này vì biểu mẫu đã trả về một tham chiếu đến đối tượng đó.

Hơn nữa, nếu tôi sai và bạn thực sự nên gửi toàn bộ đối tượng vào biểu mẫu, làm cách nào tôi có thể tách UI khỏi logic?

^{Trước hết, ví dụ bạn cung cấp không hiệu quả đến mức khó tin; nó chỉ hơi kém hiệu quả; sự kém hiệu quả của nó là dưới mức cảm nhận được. Nhưng, trong mọi trường hợp, hãy tiếp tục với câu hỏi.}

Theo cách tôi hiểu, khi chúng ta nói về sự tách biệt giữa UI và Logic , chúng ta có nghĩa là tránh sự kết hợp chặt chẽ .

Khớp nối chặt chẽ đề cập đến tình huống mà UI biết (và gọi) logic và logic biết (và gọi) UI. Để tránh khớp nối chặt chẽ, người ta không cần phải hủy bỏ hoàn toàn khớp nối. (Đó là những gì bạn dường như đang nhắm đến bằng cách phá hủy giao diện giữa chúng thành giao diện chuỗi mẫu số ít phổ biến nhất.) Tất cả một điều cần làm là sử dụng khớp nối lỏng lẻo .

Khớp nối lỏng lẻo có nghĩa là A biết B, nhưng B không biết A. Nói cách khác, hai bên liên quan đóng vai trò máy khách và máy chủ riêng biệt , trong đó máy khách biết máy chủ, nhưng máy chủ không biết máy khách.

Trong trường hợp UI và logic, cách tốt nhất để sắp xếp điều này theo ý kiến ​​của tôi là bằng cách xem logic như một máy chủ và UI như một máy khách. Vì vậy, UI được xây dựng cho logic, có kiến ​​thức về logic và gọi logic, trong khi logic không biết gì về UI và chỉ đáp ứng các yêu cầu mà nó nhận được. (Và những yêu cầu này xảy ra đến từ UI, nhưng logic không biết điều đó.)

Để đặt nó theo các thuật ngữ thực tế hơn, không nơi nào trong các tệp mã nguồn của logic bạn nên tìm thấy bất kỳ câu lệnh bao gồm / nhập / sử dụng nào tham chiếu đến tệp UI, trong khi các tệp mã nguồn của UI sẽ có đầy đủ bao gồm / nhập / sử dụng báo cáo đề cập đến các tệp Logic.

Vì vậy, để trở lại trường hợp của bạn, hoàn toàn không có gì sai với thực tế là mã UI được điền vào hộp tổ hợp biết về lớp hamburger. Sẽ có vấn đề nếu lớp hamburger biết bất cứ điều gì về hộp tổ hợp.

Ngẫu nhiên, thiết kế này cho phép một điều khác mà bạn nên mong đợi từ một hệ thống như vậy: có thể cắm nhiều UI khác nhau như bạn muốn vào logic, và toàn bộ mọi thứ vẫn hoạt động.

Bạn nên tách riêng từng phần của Mô hình, Chế độ xem & Trình điều khiển, nhưng không có lý do nào khiến bạn không thể (ví dụ) vượt qua các đối tượng Mô hình giữa Trình điều khiển và Chế độ xem.

Vì vậy, trong trường hợp của bạn, các Hamburgerđối tượng sẽ là một phần của Mô hình. Sau đó, bạn sử dụng Trình điều khiển của mình để tìm nạp danh sách cần thiết Hamburgervà chuyển các đối tượng đó vào Chế độ xem (hộp tổ hợp) để hiển thị. Khi người dùng của bạn đã chọn bánh hamburger nào, bạn có thể chuyển Hamburgerđối tượng trở lại Bộ điều khiển một lần nữa để xử lý.

Vấn đề là, bạn vẫn có thể kiểm tra đơn vị Hamburgerlogic "tìm nạp " và logic "quy trình Hamburger" tách biệt với hiển thị thực tế của hamburger.