Trong MVC, nó được coi là thực hành tốt để có các chức năng riêng tư, không hành động, trong một lớp trình điều khiển?

Đôi khi các hàm hành động trong lớp trình điều khiển có thể trở nên to lớn và khó chịu, với nhiều dòng mã chỉ đơn giản là kiểm soát luồng dữ liệu từ Mô hình đến Chế độ xem. Tại một số điểm, các hàm lớn này hoàn toàn mất dấu các nguyên tắc cơ bản của mã tốt, tức là chỉ làm một việc, nhỏ, dễ đọc và dễ quản lý, v.v.

Nó có được coi là thực hành tốt để chia các hàm hành động khổng lồ này thành các hàm riêng nhỏ hơn trong lớp trình điều khiển hay không nếu nhu cầu tối ưu hóa như vậy có nghĩa là chúng ta nên thêm chúng vào mô hình?

Tôi sẽ bỏ phiếu cho việc có các chức năng nhỏ hơn là riêng tư trong bộ điều khiển để chúng có liên quan đến hành động, nhưng tôi đã nghe thấy các đối số rằng bộ điều khiển tốt nhất nên đơn giản trong khi mô hình có thể trở nên to lớn và vón cục; và chỉ tự hỏi cái nào sẽ là phương pháp được ưa thích nhất.

Có thể không phải là sự tương tự tốt nhất, nhưng, hãy nghĩ về bộ điều khiển giống như cách bạn nghĩ về mạng nhện. Công việc duy nhất của nó là bắt ruồi (yêu cầu) để nhện (lớp bên dưới) tiêu hóa. Web có thể bắt và giữ ruồi nhỏ hơn hoặc lớn hơn (mô hình). Vai trò web của nhện không phải là để tiêu hóa con mồi, mặc dù nó có thể được sử dụng cho mục đích này. Mạng càng mỏng và sạch hơn, nhện càng dễ kiếm sống.

Bạn có thể áp dụng logic tương tự cho ứng dụng MVC của mình. Các hàm lớn và khó chịu mà bạn mô tả rất có thể là hành vi của mô hình và chúng phải thuộc về mô hình (lưu ý rằng mô hình không chỉ là đối tượng được hiển thị trong chế độ xem). Nếu hành vi của mô hình thay đổi thì đó là mô hình nên được thay đổi và không phải là bộ điều khiển xử lý nó.

Ngoài ra, giữ chúng như các phương thức riêng tư trong bộ điều khiển sẽ chỉ làm lộn xộn nó và làm cho nó khó bảo trì. Nó cũng mở đường cho một thói quen xấu, vì những người khác có liên quan đến phát triển sẽ bị cám dỗ làm điều tương tự, vì họ đã thấy nó được thực hiện trước đó trong dự án.

Câu trả lời tốt nhất tôi có thể đưa ra là trích dẫn từ cuốn sách tuyệt vời của Robert Martin, "Clean Code" mà tôi đặc biệt giới thiệu cho bất kỳ ai quan tâm đến chủ đề này:

Nguyên tắc đầu tiên của chức năng là chúng phải nhỏ. Quy tắc thứ hai là chúng nên nhỏ hơn thế.

Không thể nói nó tốt hơn. Một trích dẫn tuyệt vời khác từ cùng một cuốn sách được áp dụng:

Chức năng nên làm một việc. Họ nên làm điều đó tốt. Họ chỉ nên làm điều đó.

Khi chia mã của bạn thành nhiều hàm hơn, bạn buộc phải đặt cho các hàm đó những tên có ý nghĩa có thể cải thiện đáng kể khả năng đọc mã của bạn. Không cần phải nói, tất cả các hàm không dành cho sử dụng bên ngoài lớp, nên ở chế độ riêng tư, vì vậy bạn có thể dễ dàng sử dụng lại mã của mình thông qua kế thừa.

Nếu bộ điều khiển của bạn bây giờ có quá nhiều chức năng, đó là một dấu hiệu cho thấy nó có thể làm quá nhiều. Sau đó, bạn có thể chia nó thành nhiều phần độc lập hoặc cố gắng di chuyển một số chức năng sang các mô hình như được đề cập trong câu trả lời khác. Ngoài ra nếu bạn theo hương vị MVC phi cổ điển, trong đó Chế độ xem được phép có một số logic, bạn có thể đặt một số chức năng của mình ở đó bất cứ khi nào nó phù hợp.

Trong MVC tôi cố gắng và đảm bảo rằng bộ điều khiển của tôi càng "mỏng" càng tốt và các mô hình của tôi càng ngu ngốc càng tốt.

Các hàm trợ giúp logic và trợ giúp cần thiết được đưa vào các lớp trợ giúp độc lập riêng biệt. Nó cũng giúp cho việc kiểm tra của tôi dễ dàng hơn rất nhiều (bạn đang kiểm tra .. phải không ??: D) Kiểm soát kiểm tra rất khó khăn, bất cứ khi nào bạn thử và tạo một phiên bản của bộ điều khiển để kiểm tra bạn phải suy nghĩ về Ngữ cảnh HTTP và giả mạo http cái này và cái kia, và nó là một nỗi đau, nhưng đó là một nỗi đau về mục đích. Bạn cần tất cả những thứ đó vì bộ điều khiển được liên kết chặt chẽ với HTTP và web. Đó là điểm vào ứng dụng web của bạn.

Các hàm logic và trợ giúp không liên quan gì đến web. Họ hoàn toàn không tin tưởng vào môi trường (hoặc họ nên như vậy). Điều đó một mình sẽ nói với bạn rằng họ không thuộc về nhau ở cùng một nơi. Ngoài ra, nếu bạn liên kết chặt chẽ tất cả logic ứng dụng của mình với web hoặc triển khai web cụ thể, bạn không bao giờ có thể mang theo bên mình.

Chúng tôi đã phát triển trang web MVC của chúng tôi với tất cả các thực thể cơ sở dữ liệu của chúng tôi (không phải mô hình mvc, thực thể db thực tế của chúng tôi), lưu trữ của chúng tôi, các lớp trợ giúp và logic của chúng tôi trong riêng biệt dll. Chúng tôi chỉ có mỗi một trang web, nhưng dù sao chúng tôi cũng đã làm như vậy.

Một vài tháng trước, chúng tôi đã được yêu cầu tạo ra một vài ứng dụng máy tính để bàn có liên quan đến một vài hệ thống bên lề của chúng tôi. Điều này được thực hiện dễ dàng vì tất cả các mã được thử nghiệm của chúng tôi có thể dễ dàng được sử dụng lại. Nếu chúng tôi đưa mã của chúng tôi vào dự án web của chúng tôi hoặc đưa vào bộ điều khiển của chúng tôi, chúng tôi sẽ không bao giờ có thể làm điều này.

Bên cạnh Dmitri Zaitsev và spaceman câu trả lời tuyệt vời tôi không biết nếu những điều sau đây cũng hợp lệ đối với PHP: Bạn nên cố gắng tránh các phương thức riêng tư do thiếu khả năng kiểm tra tự động.

Có, bạn cũng có thể sử dụng siêu lập trình hoặc tiêm phụ thuộc để kiểm tra các phương thức riêng tư nhưng bạn không nên làm điều đó vì nó có tác động rất lớn đến khả năng đọc mã của bạn.

Luôn nhớ nguyên tắc KISS: Giữ cho nó đơn giản, ngu ngốc.