MVCS - Cửa hàng điều khiển xem mô hình


35

Gần đây tôi đã quyết định bắt đầu học Phát triển iOS và đến cuối cùng, tôi đã đọc Lập trình iOS: Hướng dẫn trang trại Big Nerd . Trong cuốn sách, các tác giả mô tả một mẫu thiết kế MVCS - Model-View-Controller-Store , ý tưởng cơ bản là vì nhiều ứng dụng sử dụng nhiều nguồn dữ liệu bên ngoài giữ logic yêu cầu trong bộ điều khiển có thể rất lộn xộn, thay vào đó các tác giả đề xuất rằng di chuyển tất cả logic yêu cầu ra khỏi bộ điều khiển và vào một đối tượng riêng biệt.

Tóm lại để trích dẫn cuốn sách

Model-View-Controller-Store đặt logic yêu cầu vào một đối tượng riêng biệt và chúng ta gọi đối tượng này là một cửa hàng (Hình 28.4). Sử dụng một đối tượng cửa hàng sẽ giảm thiểu mã dự phòng và đơn giản hóa mã tìm nạp và lưu dữ liệu. Quan trọng nhất, nó chuyển logic để xử lý một nguồn bên ngoài thành một lớp gọn gàng với mục tiêu rõ ràng và tập trung. Điều này làm cho mã dễ hiểu hơn, giúp duy trì và gỡ lỗi dễ dàng hơn, cũng như chia sẻ với các lập trình viên khác trong nhóm của bạn.

Điều thú vị về các cửa hàng không đồng bộ là mặc dù rất nhiều đối tượng đang thực hiện nhiều công việc để xử lý một yêu cầu, luồng yêu cầu và phản hồi của nó nằm ở một nơi trong bộ điều khiển. Điều này mang lại cho chúng ta lợi ích của mã dễ đọc và cũng dễ sửa đổi.

Tôi muốn tìm hiểu thêm về mẫu này và xem những gì người khác có thể nói về nó, nhưng trong khi tìm kiếm trực tuyến, các tài liệu tham khảo duy nhất tôi có thể tìm thấy là cùng một cuốn sách đó (có phải là mẫu có thể được biết bởi một tên khác không?).

Đối với tôi, logic của tác giả có vẻ hợp lý và có vẻ như là một phần mở rộng logic của mẫu MVC thông thường, nhưng có lẽ đó là vì tôi không thực sự có nhiều kinh nghiệm với mẫu MVC trong thực tế (ngoài việc phát triển iOS tôi có loại MVV được sử dụng với backbone.js (nghĩa là, nếu bạn xem nó là MVC )).

Tôi đã hy vọng rằng có lẽ ai đó có nhiều kinh nghiệm hơn có thể làm sáng tỏ liệu có bất kỳ sai sót / vấn đề rõ ràng nào với mẫu MVCS mà tôi đang thiếu.


2
RobotLegs trong ActionScript sử dụng "S" trong MVCS để chỉ dịch vụ. Nhưng về cơ bản nó được sử dụng theo cùng một cách. Vì vậy, có ít nhất một ví dụ khác về nó.
Amy Blankenship

1
Trong MVC, Store thường là một phần của Model. Nó được gọi là phần DAO của nó.
Florian Margaine

@FlorianMargaine đang sử dụng trái ngược với Bộ điều khiển (dường như được ngụ ý từ cuốn sách này (nó nói "Trong logic yêu cầu MVC là trách nhiệm của các đối tượng điều khiển")? Bạn có thấy bất kỳ nhược điểm rõ ràng nào khi di chuyển nó vào lớp của chính nó không ?
Jack

Câu trả lời:


18

"Store", trong trường hợp các mẫu thiết kế MVCS, có xu hướng nghiêng về logic lưu trữ. Trong trường hợp của iOS, đây thường là triển khai Dữ liệu lõi. Nếu bạn tạo mẫu được hỗ trợ Dữ liệu lõi trong Xcode, bạn sẽ thấy khía cạnh "Lưu trữ" của mẫu thiết kế này được giấu trong lớp AppDelegate.

Để đưa nó lên cấp độ tiếp theo, tôi sẽ thường tạo một lớp trình quản lý đơn lẻ xử lý việc thiết lập ngăn xếp Dữ liệu lõi và xử lý tất cả các tìm nạp / lưu có liên quan đến ngăn xếp. Như trích dẫn mà bạn đã đề cập, điều này giúp bạn không chỉ dễ dàng gọi các phương thức đó mà còn điều chỉnh chúng nếu cần, trái ngược với việc có các cuộc gọi lưu / tìm nạp ở mọi nơi trong các bộ điều khiển xem khác nhau.

Mặc dù vậy, mô hình "Cửa hàng" không bị hạn chế đối với Dữ liệu lõi. Cửa hàng của bạn có thể chỉ là một dịch vụ web. Có lẽ bạn có một lớp tương tác với Facebook, Twitter, Yelp hoặc một số API dựa trên REST khác. Tôi đã tìm thấy (và tương tự theo xu hướng) rằng các loại lớp này cũng được đặt tên là Manager. Họ thực sự quản lý tất cả các chi tiết nội bộ để các lớp khác của bạn có thể đưa vào hoặc lấy ra chính xác những gì họ cần.

Theo như những sai sót rõ ràng hoặc các vấn đề với mẫu thiết kế này ... Cũng như bất kỳ mẫu thiết kế nào, vấn đề rõ ràng nhất là đảm bảo rằng bạn đã thiết lập dự án của mình theo cách phù hợp với mô hình. Đặc biệt với một mẫu thiết kế mới đối với bạn, đôi khi đây có thể là phần khó nhất. Lợi ích của việc phá vỡ logic "Store" của bạn thành lớp riêng của nó là thực tế là nó làm cho khả năng bảo trì mã dễ dàng hơn nhiều.


Cảm ơn về cái nhìn sâu sắc, điều này thực sự giống với cách tiếp cận mà tôi đã bắt đầu thực hiện, trong đó tôi có một lớp trình quản lý đơn lẻ liên quan đến ngăn xếp dữ liệu cốt lõi và API Web.
Jack

Xin chào @jimstone, tôi hơi bối rối về logic Cửa hàng. Bạn có thể vui lòng giúp đỡ? Giả sử tôi có 5 mô hình, mỗi mô hình tôi có 2 lớp, một lớp duy trì kết nối mạng và bộ nhớ đệm khác của các đối tượng (Dữ liệu cốt lõi và nội dung). Bây giờ tôi nên có lớp Store riêng cho từng kiểu máy có chức năng gọi có chức năng gọi mạng + bộ đệm hoặc một lớp Store duy nhất có tất cả các lệnh gọi hàm + bộ đệm cho mỗi mô hình, vì vậy bộ điều khiển luôn truy cập một tệp cho dữ liệu.
thiên thạch

18

'Cửa hàng' trong ngữ cảnh này nghe rất giống Kho lưu trữ hoặc Dịch vụ . Trong trường hợp đó, đây là một mô hình cực kỳ phổ biến. Các lỗ hổng / vấn đề sẽ thay đổi theo cách triển khai của bạn và miền vấn đề.

Ở cấp độ chung, có vẻ như cuốn sách đang sử dụng 'Store' để thể hiện mức độ logic nghiệp vụ + mức logic truy xuất dữ liệu xử lý một tập hợp dữ liệu có thể hoặc không phải là một phần của ứng dụng của bạn.

Ví dụ, gói api twitter trong 'Cửa hàng' là một cách hay để ngăn chặn logic đó.

Sau khi suy nghĩ thêm
Sử dụng định nghĩa này của MVC (mà tôi nghĩ là khá hay), 'Store' thực sự là một tập hợp con của mô hình. Phân định giữa việc nó là một phần mở rộng cho MVC hay liệu đó là một mẫu truy xuất dữ liệu không hữu ích lắm. Họ cuối cùng trông giống như mã.

Tóm lại, tôi nghĩ bạn sẽ ổn theo lời khuyên mà họ đề xuất (có vẻ như âm thanh tổng thể).


1
Đọc qua các liên kết bạn cung cấp Nghe có vẻ tương tự, ngoại trừ ở đây nó được sử dụng như một phần mở rộng cho mẫu MVC.
Jack

5
+1, có vẻ như họ vừa nghĩ ra một tên mới cho mẫu kho lưu trữ (kho lưu trữ là một loại dịch vụ).
MattDavey
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.