MVC - phương thức nào phải ở trong Lớp mô hình ngoại trừ thiết lập/nhận thành viên?

Question

Phương pháp thực hiện thao tác trên Mô hình bộ ghi nhớ lớp học phải được thực hiện trên Mẫu hoặc trong Bộ điều khiển ? Liệu nó phụ thuộc vào cách thao tác này "nặng" như thế nào?

"thao tác" Ý tôi là - có được một thành viên trong lớp, tính toán dài dựa trên anh ta và sau đó trả về một giá trị khác có liên quan đến lớp này.

Ví dụ - có Board class giữ thành viên ma trận ô, bây giờ tôi muốn triển khai phương thức trả về tất cả các ô xung quanh theo vị trí ô cụ thể. ai chịu trách nhiệm thực hiện ở trên?

Nếu câu hỏi này thuộc về một QA Stack Exchange khác, bạn sẽ được chào đón để gửi bài đăng.

Answer 1

Điều bạn gọi là "mô hình" thực ra là domain objects. Các mô hình thực tế trong MVC chỉ là một lớp, không phải là điều cụ thể.

Trong ví dụ cụ thể của bạn, Board phải có phương thức trả về danh sách này. Tôi cho rằng, bạn đang thực sự có được nó bởi vì bạn cần phải tiếp tục tương tác với những tế bào đó.

Đây là nơi mà services trong lớp mô hình được đưa vào để phát. Nếu bạn sử dụng chúng, chúng là phần bên ngoài của lớp mô hình và chứa logic ứng dụng - tương tác giữa các đối tượng miền khác nhau và tương tác giữa độ bền (thường là data mappers hoặc units of work) và đối tượng miền.

Giả sử bạn đang tạo trò chơi và bạn cũng như người chơi thực hiện và tấn công AoE. Bộ điều khiển sẽ giữ một dịch vụ, chịu trách nhiệm về chức năng này và gửi một lệnh: trình phát này nhắm AoE theo hướng này, thực hiện nó.

Dịch vụ instantiates Board và yêu cầu các ô xung quanh vị trí mục tiêu. Sau đó, nó thực hiện "thiệt hại" trên mỗi tế bào trong bộ sưu tập mà nó có được. Sau khi thực hiện xong logic, nó báo cho cá thể Unit of Work thực hiện tất cả các thay đổi đã xảy ra trên Board.

Bộ điều khiển không quan tâm đến chi tiết về dịch vụ nào. Và nó sẽ không nhận được bất kỳ phản hồi nào. Khi thực hiện được xem, nó yêu cầu từ lớp mô hình những thay đổi mới nhất và sửa đổi giao diện người dùng. Khi các lợi ích bổ sung - các dịch vụ cho phép bạn ngăn chặn logic nghiệp vụ khỏi bị rò rỉ trong lớp trình bày (chủ yếu được tạo thành từ các khung nhìn một bộ điều khiển).

Đối tượng miền chỉ nên chứa các phương thức xử lý trạng thái của chúng.

Answer 2

Giữ bộ điều khiển của bạn mỏng, không để chúng hoạt động nhiều, điều này phù hợp với Nguyên tắc về trách nhiệm duy nhất trong SOLID cho thiết kế hướng đối tượng. Nếu bạn có bộ điều khiển chất béo, họ trở nên khó kiểm tra và duy trì. Đối với các mô hình, trước đây tôi đã từng có các mô hình câm trước đó nhưng không có gì ngoài việc ánh xạ tới các bảng cơ sở dữ liệu và được lấy cảm hứng từ hầu hết các ứng dụng mẫu mà bạn thấy trên web, nhưng bây giờ tôi không làm điều đó .

Tôi (cố gắng) tuân theo nguyên tắc từ Thiết kế điều khiển tên miền, nơi các mô hình (thực thể trong điều khoản DDD) là trung tâm của ứng dụng, chúng được dự kiến ​​sẽ đóng gói hành vi liên quan đến thực thể, chúng là mô hình thông minh (vì vậy có, logic liên quan đến một đối tượng sẽ sống với nó trong trường hợp đó). DDD là một chủ đề lớn hơn và nó không liên quan trực tiếp đến MVC, nhưng các nguyên tắc đằng sau nó giúp bạn thiết kế ứng dụng của bạn tốt hơn, có rất nhiều tài liệu và ứng dụng mẫu có sẵn nếu bạn google DDD.

Ngoài ra, cộng đồng Ruby On Rails - mà dường như truyền cảm hứng cho hầu hết các khung MVC - cũng có vẻ có một sự cường điệu xung quanh có Mô hình Chất béo và Bộ điều khiển Gầy.

Trên hết, bạn có thể thêm Xem mô hình vào danh sách kết hợp mà tôi thấy hữu ích. Trong trường hợp này, bạn có thể có một ViewModel đại diện cho một tập con câm của (các) mô hình của bạn chỉ để sử dụng để tạo khung nhìn, nó giúp cuộc sống của bạn dễ dàng hơn và tách biệt hơn nữa khỏi các Mô hình của bạn để chúng không ảnh hưởng đến thiết kế của bạn quyết định không cần thiết.

Answer 3

Tôi nghĩ rằng điều này ít liên quan đến MVC và nhiều thứ khác liên quan đến kỹ thuật phần mềm thông thường.

Cá nhân tôi sẽ không ngần ngại gắn các phép tính tầm thường trong một mô hình, nhưng sẽ cực kỳ cảnh giác với các mô hình chất béo.

Bây giờ, thực tế MVC là viết tắt của Trình điều khiển xem mô hình không nhất thiết có nghĩa là mọi thứ phải là chế độ xem, mô hình hoặc bộ điều khiển. Nếu bạn cảm thấy cần phải di chuyển trách nhiệm đến một lớp học riêng biệt mà không thực sự đủ điều kiện như là một M, một V hoặc C, tôi không thấy lý do tại sao bạn không nên làm điều đó.

Cách bạn triển khai tùy thuộc vào bạn. Bạn có thể sử dụng lớp riêng biệt này như một đối tượng "cấp cao nhất" (vì thiếu một thuật ngữ tốt hơn), hoặc tạo một phương thức của mô hình ủy quyền cho nó, để che giấu thực tế là bạn đang sử dụng nó. Tôi có lẽ sẽ đi cho thứ hai.

Mọi thứ đều có thể gây tranh cãi.Mọi người và em gái của họ dường như có một ý kiến ​​khác nhau về cách làm MVC đúng.

Tôi chỉ xem đó là phương châm. Chắc chắn, đó là một ý tưởng tuyệt vời vì nó dẫn bạn đến sự phân chia mối quan tâm tốt hơn, nhưng cuối cùng - vì nó luôn luôn xảy ra - không có cách nào phù hợp để áp dụng nó, và bạn không nên bị ràng buộc quá mức bởi nó , đến mức mọi thứ phải là chế độ xem, mô hình hoặc bộ điều khiển.

Answer 4

Theo thực tiễn tốt nhất, chúng ta nên sử dụng các thuộc tính cho các trường được Tính toán chỉ có quyền truy cập. ví dụ công khai tổng cộng đôi TotalCost { nhận được { trả lại this.Role.Cost * TotalHour; } }