Bao nhiêu logic kinh doanh nên được phép tồn tại trong lớp điều khiển?

Đôi khi chúng ta có một số logic nghiệp vụ được thể hiện trong mã điều khiển của các ứng dụng của chúng ta. Đây thường là logic phân biệt các phương thức để gọi từ mô hình và / hoặc đối số nào để truyền chúng.

Một ví dụ khác về điều này là một tập hợp các hàm tiện ích tồn tại trong bộ điều khiển có thể hoạt động để định dạng hoặc vệ sinh dữ liệu được trả về từ mô hình, theo một bộ quy tắc kinh doanh.

Điều này hoạt động, nhưng tôi tự hỏi nếu nó tán tỉnh với thảm họa. Nếu có logic nghiệp vụ được chia sẻ giữa bộ điều khiển và mô hình, hai lớp không còn có thể tách rời và ai đó kế thừa mã có thể bị nhầm lẫn bởi sự không đồng đều này ở vị trí của mã liên quan đến logic nghiệp vụ.

Câu hỏi của tôi là bao nhiêu logic kinh doanh nên được cho phép trong bộ điều khiển và trong trường hợp nào, nếu có?

Không có lý tưởng

Nhưng điều đó không phải lúc nào cũng có thể. Tôi không thể cung cấp cho bạn các số khó như 20% hoặc 10 dòng, điều này chủ quan đến điểm không thể trả lời được. Tôi có thể mô tả cách tôi sử dụng các mẫu thiết kế và hoàn cảnh bắt buộc phải uốn cong chúng một chút.

Trong tâm trí của tôi, nó hoàn toàn phụ thuộc vào mục đích của ứng dụng. Xây dựng một api REST đơn giản để đăng lên? Hãy quên đi sự tách biệt sạch sẽ hoặc thậm chí là một mô hình. Bạn có thể tạo ra một phiên bản làm việc trong vòng một giờ. Xây dựng cái gì lớn hơn? Có lẽ tốt nhất để làm việc trên nó.

Xây dựng các hệ thống chứa cá nhân là mục tiêu. Nếu bạn bắt đầu viết logic kinh doanh cụ thể cho cách hai hệ thống tương tác thì đó là một vấn đề. Không cần nhìn sâu hơn vào nó, tôi không thể đưa ra ý kiến.

Các mẫu thiết kế là khuôn mẫu, một số thích tuân thủ nghiêm ngặt chúng trên cơ sở mã chính và được viết tốt. Tuân thủ nghiêm ngặt một mẫu có thể sẽ không cung cấp cho bạn mã xấu , nhưng nó có thể mất nhiều thời gian hơn và khiến bạn phải viết nhiều mã hơn .

Mẫu thiết kế rất linh hoạt, điều chỉnh chúng cho phù hợp với nhu cầu của bạn . Bẻ cong chúng quá nhiều và họ phá vỡ mặc dù. Biết những gì bạn cần và chọn một mẫu thiết kế gần nhất với điều đó.

Càng ít càng tốt. Tốt nhất là không có.

Bộ điều khiển nên quan tâm đến việc chấp nhận yêu cầu, yêu cầu dịch vụ tên miền chính xác xử lý yêu cầu và đưa ra phản hồi cho chế độ xem chính xác.

Trong quá trình đó, tất cả "logic kinh doanh" phải tồn tại trong các dịch vụ miền.

Nếu bạn có chức năng lấy các đối tượng miền và tạo các khung nhìn ra khỏi chúng, thì điều đó có thể cùng tồn tại hợp lý với bộ điều khiển. Nhưng đó phải là mã chỉ tồn tại vì lợi ích của các khung nhìn tương ứng. Nếu có một quy tắc cấp doanh nghiệp về vệ sinh dữ liệu, thì điều đó sẽ tồn tại trong cấp độ tên miền / dịch vụ của bạn (với các bài kiểm tra đơn vị bị khủng bố).

Thuật ngữ "logic kinh doanh" là một từ thường gây nhầm lẫn bởi vì mọi người có ý kiến ​​khác nhau về ý nghĩa của điều này. Theo quan điểm của tôi, thuật ngữ "logic kinh doanh" bao gồm hai lĩnh vực

• Logic miền
• Logic ứng dụng

Logic Logic là logic liên quan đến lĩnh vực cốt lõi mà bạn kinh doanh liên quan, vì vậy nếu viết một ứng dụng cho kế toán, thì quy tắc thuế, quy tắc giữ sổ, v.v. là một phần của logic miền.

Logic ứng dụng là logic liên quan đến thực tế là bạn đang chạy một chương trình máy tính. Đây có thể là những thứ như xuất nhập CSV, trình hướng dẫn, v.v. Cũng có thể chứa những thứ như tạo email quên mật khẩu.

Loại "logic nghiệp vụ" mà bạn có thể đặt trong lớp trình điều khiển là Logic ứng dụng. Có lẽ không phải tất cả logic ứng dụng nên đến đó. Nhưng bạn không bao giờ nên đặt logic miền trong lớp điều khiển. Điều đó rõ ràng nên ở trong lớp miền.

Bạn đang nói về logic để định dạng hoặc vệ sinh dữ liệu. Định dạng chắc chắn phải là logic ứng dụng. Mặt khác, vệ sinh có thể là logic miền, nếu vệ sinh dữ liệu dựa trên các quy tắc miền. Điều đó phụ thuộc vào bối cảnh.

Bộ điều khiển nên rất nhẹ về logic miền.

Bộ điều khiển nên ủy thác các tác vụ như truy xuất bản ghi từ kho lưu trữ dữ liệu bằng cách sử dụng lớp dịch vụ / kho lưu trữ trừu tượng và chuyển dữ liệu trở lại kho lưu trữ dữ liệu bằng cùng một dịch vụ (hoặc có liên quan). Đối với các cơ học và hoạt động tốt hơn giữa các hoạt động đó, thường chúng thuộc về một nơi khác ngoài bộ điều khiển.

Tôi thường thấy mình thêm các phương pháp vệ sinh dữ liệu nhỏ vào bộ điều khiển để lưu dữ liệu trở lại cửa hàng và mặc dù đây là một giải pháp hiệu quả, nhưng nó không phù hợp với vai trò dự định của bộ điều khiển. Lý tưởng nhất, bất cứ điều gì sẽ được sửa đổi, xác nhận hoặc phân tích mô hình của bạn sẽ xảy ra rất gần - nếu không nằm trong chính mô hình đó. Ví dụ: nếu bạn cần 'dọn dẹp' một đối tượng mô hình trước khi lưu trữ nó, hãy xem xét có phương thức SanitizeInputs () trên mô hình hoặc là một phần của dịch vụ xử lý việc lưu trữ mô hình.

Từ quan điểm thực dụng tôi đã thấy rằng bạn kết thúc bằng logic trong bộ điều khiển hoặc hành vi của bộ điều khiển trong mô hình của bạn khi bạn đang cố gắng làm một cái gì đó không phải là một cách tiếp cận tuân thủ mô hình tốt. Chắc chắn là như vậy nếu bạn đang viết một ứng dụng không có cơ sở hạ tầng lớn đằng sau nó.

Bạn có thể đi một trong hai cách, nhưng tôi thường cố gắng nghĩ xem liệu bit lạ có khả năng xuất hiện trong nhiều hơn một hành động của bộ điều khiển hay không, nếu vậy nó đi trong mô hình. Nếu điều đó không rõ ràng, tôi cố gắng suy nghĩ nếu nó "phù hợp" ở một nơi hơn nơi khác. Không thể tôi thường đặt nó trong mô hình chỉ để tránh xa bộ điều khiển (ưu tiên cá nhân cho các bộ điều khiển nhỏ hơn và các đối tượng dữ liệu mạnh hơn, YMMV)

Tùy chọn thứ ba sẽ là tham chiếu các mục tiện ích như một lớp tiện ích riêng biệt, nhưng điều đó hơi chống lại mô hình cũng như theo ý kiến ​​của nhiều người.

Ngoài ra, chỉ vì bạn không tuân thủ nghiêm ngặt một mô hình mà bạn không nhất thiết phải tán tỉnh với thảm họa. Trừ khi bạn thực sự mong đợi một lượng mã đáng kể sử dụng lại dự án này, tôi sẽ lo lắng rất nhiều về dự án phù hợp với chính nó (ví dụ: không được lật ở nơi bạn đặt các bit này khi bạn chọn vị trí) hơn là viết lại rằng vì lý do nào đó muốn tiết kiệm một phần giữa dự án. Tài liệu / nhận xét ở đâu & tại sao bạn đi chệch khỏi mẫu chung và xác định mẫu dự kiến ​​cho ứng dụng này.

MVC là một sai lệch so với các mẫu được thiết lập tại một thời điểm.

Giống như nhiều khái niệm thú vị khác trong lập trình, MVC là một mô hình mạnh mẽ để mang cấu trúc và tập trung vào một gia đình có các chiến lược gần hoặc tương tự để thực hiện các kịch bản nhất định.

Giống như nhiều khái niệm lập trình khác, MVC đơn giản hóa thực tế, loại bỏ các chi tiết nhỏ và cung cấp một mô hình khung dây thô để làm theo. Giống như nhiều sự đơn giản hóa khác của thực tế, nó làm việc ny đưa cấu trúc vào hỗn loạn như được nhìn thấy bởi một tâm trí con người.

Tuy nhiên, giống như nhiều khái niệm lập trình khác, MVS chỉ là một sự đơn giản hóa của thực tế. Nó không hoàn hảo và nó không kỹ lưỡng. Đó là lý do tại sao không thể phù hợp với một kịch bản trong thế giới thực vào một mô hình đơn giản hóa. Do đó phát sinh nhiều câu hỏi tương tự như câu hỏi này.

• Bao nhiêu logic nên đi vào một bộ điều khiển?

• Liệu một khung nhìn nên chứa bất kỳ logic có điều kiện?

• Liệu một mô hình có nên chứa bất kỳ dữ liệu bổ sung nào không được tìm thấy trực tiếp trong các thực thể kinh doanh không?

Đây là tất cả các câu hỏi sinh ra trong nỗ lực điều chỉnh mã để phù hợp với ý tưởng khái niệm về MVC một cách chính xác và hoàn toàn.

Câu trả lời của tôi cho bạn là đừng cố gắng. MVC cung cấp cấu trúc. Xây dựng ứng dụng của bạn xung quanh nền tảng này nhưng đừng hy vọng nó phù hợp hoàn hảo. Sẽ có những sai lệch, đó là bình thường. Chỉ cần xem để giữ chúng trong tầm kiểm soát.