Xử lý logic tại Controller hay Model?

#1

Mình đang học CI, mình có một vài thắc mắc muốn nhờ các bạn giải đáp:
Theo hiểu biết MVC của mình: Model thao tác với cơ sở dữ liệu trả về dữ liệu cần tìm, Controller sẽ lấy dữ liệu trả về của Model đồng thời việc Controller sẽ dùng dữ liệu của Model để xử lý logic tại đây và truyền dữ liệu qua View.

  1. Việc mình xử lý logic tại Controller đã hợp lý chưa?
    Controller
    controller.JPG1017×602 90.5 KB

    Model
    model.JPG773×538 51.1 KB

    View
    view.JPG1019×604 77.6 KB
  2. Lúc trước mình có dạo fb thì có vô tình đọc 1 cmt của một bạn k nhớ rõ tên nhưng bạn ý có nói là : tại Model cũng có thể xử lý Logic. Vậy xử lý logic tại Model có được không??
  3. Lúc trước mình có làm 1 web nho nhỏ nhưng gặp vấn đề mình k giải quyết được trong Controller. Nên mình đã lấy dữ liệu của Model ngay trong view mà không qua Controller tức là trong view mình gọi đến phương thức Model tương ứng để lấy dữ liệu. Mình làm như vậy có được không?
#2

mình hay để phần xử lý form ở model :smiley: và các các logic. còn lại điều hướng mình chuyển sang controller.

1 Like
#3
  1. Anh thấy em viết code như vậy là hợp lý.
  2. Mô hình MVC được thiết kê giúp cho việc quản lý code tốt hơn. Tránh trường hợp chồng chéo code từ giao diện(View), xử lý logic business(Controller), xử lý database(Model). Dĩ nhiên sẽ có trường hợp ngoại lệ xử lý logic business ở Model hay mang Model lên View. Nhưng phải xem xét kỹ khi quyết định làm điều này. Vì sẽ mất thời gian sau này cho quá trình bảo trì code.
1 Like
#4

mình để logic ở controller, model của mình chỉ tương tác với database thôi :smiley:

#5

Nếu bạn áp dụng mô hình MVC một cách “lý tưởng” thì bạn sẽ có “Fat Model” + “Thin Controller”. Nghĩa là mọi business logic sẽ nằm ở Model, Controller chỉ nhận nhiệm vụ điều phối và xử lý những logic đơn giản giữa M và V là chính. Nếu trường hợp của bạn đơn giản quá thì bạn có thể để trong Controller luôn cũng được, miễn là bạn cảm thấy nó dễ bảo trì và phát triển thêm, không nhất thiết phải 100% theo design pattern :smile:

7 Likes
#6

thông thường để rõ ràng nhất và linh hoạt thì phần business logic nên được xử lý ở một lớp trung gian được gọi là Service Layer tầng này sẽ xử lý những câu truy vấn đến database như Create, Update, Delete … Sau đó từ Controller chúng ta sẽ gọi tầng Service này lên để sử dụng.

4 Likes
#7

Trước giờ mình chỉ nghe nói đến là xử lý logic, vậy business logic là gì vậy???

#8
#9

Ai có thể liệt kê các trường hợp không thể để trong model không? Mình nghĩ nên liệt kê ra, mọi người cùng phân tích

1 Like
#10

Nếu bạn vẫn chưa hiểu rõ về MVC, thì mình khuyên bạn nên dành thời gian đọc qua quyển sách này (rất xúc tích, dễ hiểu và chứa nhiều design pattern phổ dụng khác). Mình ước gì mình đã đọc nó sớm hơn trước khi lao đầu vào các framework :smiley:

Patterns of Enterprise Application Architecture (1st Edition) by Martin Fowler

1 Like
#11

code cơ bản nhìn tàm tạm nhưng không thoả mãn Single Responsibility Principle

2 Likes
#12

Tôi cũng đang tự học, nhưng theo tôi thì nếu đã theo MVC thì nên phân tách rạch ròi M V và V, mỗi phần có nhiệm vụ riêng mặc dù có thể làm hộ nhau đc. Điều hướng là việc của anh router, xử lý logic là của anh C, M chỉ biết tuân lệnh anh C để thao tác với CSDL còn cuối cùng là anh V chỉ việc render dữ liệu nếu có, không đc xử lý gì tại view, như vậy cùng 1 form view có thể dùng cho nhiều controller đc và tận dụng sức mạnh của MVC. Chúc bạn thành công.

#13

Đồng quan điểm với bạn. nên để trong service, tính tái sử dụng code cao hơn. Cách này tuy đơn giản mà hiệu quả, code dễ bảo trì.

1 Like
#14

bạn nên tạo ra một thằng service chuyên sử lý logic tương tác với model rồi controller gọi nó

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?