Tôi có 2 câu hỏi:Logic nghiệp vụ trong MVC
Q1. Trường hợp chính xác "logic kinh doanh" nằm trong mô hình MVC? Tôi bối rối giữa Model và Controller.
Q2. Có phải "logic nghiệp vụ" giống như "quy tắc kinh doanh" không? Nếu không, sự khác biệt là gì?
Sẽ rất tuyệt nếu bạn có thể giải thích bằng một ví dụ nhỏ.
Quy tắc kinh doanh có trong mô hình.
Giả sử bạn đang hiển thị email cho danh sách gửi thư. Người dùng nhấp vào nút "xóa" bên cạnh một trong các email, trình điều khiển thông báo cho mô hình để xóa mục nhập N, sau đó thông báo cho chế độ xem mô hình đã thay đổi.
Có thể email của quản trị viên sẽ không bao giờ bị xóa khỏi danh sách. Đó là một quy tắc kinh doanh, kiến thức đó thuộc về mô hình. Quan điểm cuối cùng có thể là đại diện cho quy tắc này bằng cách nào đó - có lẽ mô hình cho thấy một thuộc tính "IsDeletable" là một chức năng của quy tắc kinh doanh, do đó nút xóa trong chế độ xem bị tắt cho các mục nhất định - nhưng chính quy tắc đó không phải là ' t chứa trong khung nhìn.
Mô hình cuối cùng là gatekeeper cho dữ liệu của bạn. Bạn sẽ có thể kiểm tra logic nghiệp vụ của mình mà không cần chạm vào giao diện người dùng.
A1: Logic nghiệp vụ đi tới Model một phần trong MVC. Vai trò của Model là chứa dữ liệu và logic nghiệp vụ. Controller mặt khác chịu trách nhiệm nhận dữ liệu nhập của người dùng và quyết định phải làm gì.
A2: A Business Rule là một phần của Business Logic. Họ có mối quan hệ has a. Business Logic có Business Rules.
Hãy xem Wikipedia entry for MVC. Chuyển đến Tổng quan nơi đề cập đến luồng của mẫu MVC.
Ngoài ra, hãy xem Wikipedia entry for Business Logic. Được đề cập rằng Business Logic bao gồm Business Rules và Workflow.
Thuật ngữ logic kinh doanh theo ý kiến của tôi không phải là định nghĩa chính xác. Evans nói trong cuốn sách của mình, Domain Driven Design, về hai loại logic nghiệp vụ:
Sự phân tách này theo ý kiến của tôi rõ ràng hơn rất nhiều. Và với việc nhận ra rằng có nhiều loại quy tắc kinh doanh khác nhau cũng xuất hiện mà họ không nhất thiết phải đi cùng một nơi.
Logic miền là logic tương ứng với miền thực tế. Vì vậy, nếu bạn đang tạo một ứng dụng kế toán, quy tắc miền sẽ là các quy tắc liên quan đến tài khoản, bài đăng, thuế, v.v. Trong một công cụ lập kế hoạch phần mềm nhanh nhẹn, các quy tắc sẽ là công cụ như tính toán ngày phát hành dựa trên vận tốc và điểm câu chuyện. v.v.
Đối với cả hai loại ứng dụng này, nhập/xuất CSV có thể có liên quan, nhưng quy tắc nhập/xuất CSV không liên quan gì đến miền thực tế. Loại logic này là logic ứng dụng.
Logic miền chắc chắn nhất sẽ rơi vào lớp mô hình. Mô hình cũng sẽ tương ứng với lớp miền trong DDD.
Tuy nhiên, logic ứng dụng không nhất thiết phải được đặt trong lớp mô hình. Điều đó có thể được đặt trực tiếp trong bộ điều khiển hoặc bạn có thể tạo một lớp ứng dụng riêng biệt lưu trữ các quy tắc đó. Điều gì là hợp lý nhất trong trường hợp này sẽ phụ thuộc vào ứng dụng thực tế.
Điều này rất đúng! Có hai mô hình ở đây là Kiểu xem và Mô hình miền của bạn. Tôi nghĩ rằng nó gần như không may rằng bố trí của các dự án MVC dẫn các nhà phát triển mới làm quen để tin rằng họ chỉ nên nhồi nhét mã của họ vào View Model. – Jonathan
Tìm thấy câu trả lời của bạn dễ chấp nhận hơn và dễ hiểu hơn. Cảm ơn. – revo
Mẫu = mã cho các hoạt động cơ sở dữ liệu CRUD.
Bộ điều khiển = phản hồi hành động của người dùng và chuyển yêu cầu của người dùng để truy xuất dữ liệu hoặc xóa/cập nhật mô hình, tuân theo quy tắc kinh doanh cụ thể cho một tổ chức. Những quy tắc kinh doanh này có thể được thực hiện trong các lớp trợ giúp, hoặc nếu chúng không quá phức tạp, chỉ cần trực tiếp trong các hành động của bộ điều khiển. Bộ điều khiển cuối cùng yêu cầu xem để cập nhật chính nó để cung cấp phản hồi cho người dùng dưới dạng màn hình mới hoặc thông báo như 'cập nhật, cảm ơn', v.v.,
Chế độ xem = Giao diện người dùng được tạo dựa trên một truy vấn trên mô hình.
Không có quy tắc cứng và nhanh nào về quy tắc kinh doanh nên đi đâu. Trong một số mẫu thiết kế, chúng đi vào mô hình, trong khi ở những người khác chúng được bao gồm với bộ điều khiển. Nhưng tôi nghĩ tốt hơn là giữ chúng với bộ điều khiển. Hãy để mô hình chỉ lo lắng về kết nối cơ sở dữ liệu.
Nếu bạn đặt các quy tắc nghiệp vụ trong bộ điều khiển và bạn có nhiều, nhiều hành động - bạn sẽ lặp lại quy tắc nghiệp vụ nhiều lần? Không. Bạn sẽ tách nó trong một phương thức trợ giúp hoặc một lớp nào đó. Đặt "điều" đó vào mô hình, nơi nó thuộc về. –
MVC không phải là một mẫu ứng dụng cho các hoạt động cơ sở dữ liệu CRUD (mặc dù nó có thể được sử dụng theo cách đó) do đó Mô hình không thể là "mã cho các hoạt động cơ sở dữ liệu CRUD". Mô hình xác định các thực thể của ứng dụng, bao gồm dữ liệu và các quy tắc nghiệp vụ. Bộ điều khiển điều phối tương tác giữa chế độ xem và mô hình. Giao diện là giao diện người dùng hiển thị mô hình và các hoạt động có sẵn trong các mô hình được bộ điều khiển tiếp xúc. –
Nắm tay của tất cả:
Tôi tin rằng bạn đang trộn lẫn nguyên tắc thiết kế dựa trên nền tảng MVC và n-tier.
Sử dụng cách tiếp cận MVC không có nghĩa là bạn không nên lớp ứng dụng của mình.
Nó có thể hữu ích nếu bạn thấy MVC giống như một phần mở rộng của lớp trình bày.
Nếu bạn đặt mã không trình bày bên trong mẫu MVC, bạn có thể sẽ sớm xuất hiện trong một thiết kế phức tạp.
Vì vậy, tôi khuyên bạn nên đặt logic nghiệp vụ của mình vào một lớp kinh doanh riêng biệt.
Chỉ cần có một cái nhìn lúc này: Wikipedia article about multitier architecture
Nó nói:
Hôm nay, MVC và tương tự như model-view-người dẫn chương trình (MVP) là Tách mẫu Mối quan tâm thiết kế được áp dụng riêng cho các lớp trình bày của một hệ thống lớn hơn.
Dù sao ... khi nói về một ứng dụng web doanh nghiệp các cuộc gọi từ UI đến lớp logic kinh doanh nên được đặt bên trong (trình bày) điều khiển.
Đó là do bộ điều khiển thực sự xử lý các cuộc gọi đến một tài nguyên cụ thể, truy vấn dữ liệu bằng cách thực hiện cuộc gọi đến logic nghiệp vụ và liên kết dữ liệu (mô hình) với chế độ xem phù hợp.
Bùn nói với bạn rằng các quy tắc kinh doanh đi vào mô hình.
Điều đó cũng đúng, nhưng ông đã trộn lẫn mô hình (bản trình bày) ('M' trong MVC) và mô hình lớp dữ liệu của thiết kế ứng dụng dựa trên tầng.
Vì vậy, nó là hợp lệ để đặt doanh nghiệp liên quan đến cơ sở dữ liệu của bạn quy tắc trong mô hình (lớp dữ liệu) của ứng dụng của bạn.
Nhưng bạn không nên đặt chúng trong mô hình của lớp trình bày có cấu trúc MVC vì điều này chỉ áp dụng cho một giao diện người dùng cụ thể.
Kỹ thuật này độc lập với thời tiết, bạn sử dụng thiết kế hướng theo miền hoặc phương pháp tiếp cận dựa trên tập lệnh giao dịch.
Hãy để tôi hình dung đó cho bạn: lớp
Trình bày: Model - View - Controller
lớp kinh doanh: Miền logic - Ứng dụng Logic
Lớp dữ liệu: Kho dữ liệu - Lớp truy cập dữ liệu
Mô hình mà bạn thấy ở trên có nghĩa là bạn có ứng dụng sử dụng MVC, DDD và lớp dữ liệu riêng biệt cơ sở dữ liệu.
Đây là phương pháp phổ biến để thiết kế ứng dụng web doanh nghiệp lớn hơn.
Nhưng bạn cũng có thể thu nhỏ nó xuống để sử dụng một lớp kinh doanh không DDD đơn giản (một lớp nghiệp vụ không có logic miền) và một lớp dữ liệu đơn giản ghi trực tiếp vào cơ sở dữ liệu cụ thể.
Bạn thậm chí có thể thả toàn bộ lớp dữ liệu và truy cập cơ sở dữ liệu trực tiếp từ lớp nghiệp vụ, mặc dù tôi không khuyên bạn nên.
Thats' lừa ... Tôi hy vọng điều này sẽ giúp ...
[Lưu ý:] Bạn cũng nên nhận thức được thực tế là hiện nay có nhiều hơn chỉ là một 'mô hình' trong một ứng dụng. Thông thường, mỗi lớp của một ứng dụng có mô hình riêng của nó. Mô hình của lớp trình bày được xem cụ thể nhưng thường độc lập với các điều khiển được sử dụng. Lớp nghiệp vụ cũng có thể có một mô hình, được gọi là "mô hình miền". Đây thường là trường hợp khi bạn quyết định sử dụng phương pháp tiếp cận theo miền. "Mô hình miền" này chứa dữ liệu cũng như logic nghiệp vụ (logic chính của chương trình của bạn) và thường độc lập với lớp trình bày. Lớp trình bày thường gọi lớp doanh nghiệp trên một "sự kiện" nhất định (nút được nhấn vv) để đọc dữ liệu từ hoặc ghi dữ liệu vào lớp dữ liệu. Lớp dữ liệu cũng có thể có mô hình riêng của nó, thường là cơ sở dữ liệu liên quan. Nó thường chứa một tập các lớp thực thể cũng như các đối tượng truy cập dữ liệu (DAO).
Câu hỏi đặt ra là: điều này phù hợp với khái niệm MVC như thế nào?
Trả lời -> Không!
Vâng - có thể, nhưng không hoàn toàn.
Điều này là do MVC là một cách tiếp cận được phát triển vào cuối những năm 1970 cho ngôn ngữ lập trình Smalltalk-80. Vào thời điểm đó GUI và máy tính cá nhân khá phổ biến và trên toàn thế giới web thậm chí không được phát minh! Hầu hết các ngôn ngữ lập trình và IDE ngày nay được phát triển vào những năm 1990. Vào thời điểm đó, máy tính và giao diện người dùng hoàn toàn khác so với những năm 1970.
Bạn nên ghi nhớ điều đó khi nói về MVC.
Martin Fowler has written a very good article about MVC, MVP and today's GUIs.
+1 để liệt kê chính xác sự khác biệt giữa ứng dụng mvc và n-tier. Hầu hết các ứng dụng doanh nghiệp mà tôi phát triển có n-tier và chỉ sử dụng mvc làm lớp trình bày. –
+1 để giải thích sự khác biệt. – ziggy
Cho phép nói 1) Xem mô hình trong MVC (Lớp trình bày) 2) Một số công nghệ C# (Lớp kinh doanh) cho Giao dịch được ủy quyền, Quy tắc kinh doanh cốt lõi Logic. 3) Kho lưu trữ và đơn vị công việc trong (Lớp truy cập dữ liệu) Vui lòng hướng dẫn một số công nghệ (hoặc Mẫu thực hành tốt nhất) có thể được sử dụng để xây dựng Lớp kinh doanh. lớp (Lớp trên). Về cơ bản tôi tin rằng Thêm, Xóa, Cập nhật & Kết hợp của nó dưới dạng Logic nghiệp vụ và phải được giữ trong Giao dịch. Vui lòng truyền thêm một số ánh sáng về điều này. –
Đây là một câu hỏi đã trả lời, nhưng tôi sẽ cung cấp cho tôi "một xu":
quy tắc kinh doanh thuộc trong mô hình. "Mô hình" luôn luôn bao gồm (hợp lý hoặc tự tách ra):
Quy tắc kinh doanh trực tiếp trong mô hình miền, được hiển thị dưới dạng bản trình bày phù hợp với mô hình "bản trình bày" và đôi khi được nhân đôi (hoặc được thi hành) trong "lớp dữ liệu".
Đó là một góc nhìn ngắn gọn, cảm ơn. – Maxcot
Q1:
logic kinh doanh có thể được xem xét trong hai loại:
miền logic như điều khiển trên một địa chỉ email (tính độc đáo, khó khăn, vv), lấy giá của một sản phẩm hóa đơn, hoặc tính tổng giá của mua sắm dựa trên các đối tượng sản phẩm của nó.
Quy trình nghiệp vụ phức tạp hơn, được gọi là quy trình nghiệp vụ, như kiểm soát quá trình đăng ký cho sinh viên (thường bao gồm nhiều bước và cần kiểm tra khác nhau và có những hạn chế phức tạp hơn).
Các loại đầu tiên đi vào mô hình và thứ hai một thuộc về khiển. Điều này là do các trường hợp trong thể loại thứ hai là các logic ứng dụng rộng và đưa chúng vào mô hình có thể kết hợp sự trừu tượng của mô hình (ví dụ, nó không rõ ràng nếu chúng ta cần đưa các quyết định đó vào một lớp mô hình hay lớp khác, vì chúng có liên quan cho cả hai!).
Xem điều này answer để biết sự khác biệt cụ thể giữa mô hình và bộ điều khiển, link này cho các định nghĩa rất chính xác và cũng có thể là link cho ví dụ Android tuyệt vời này.
Vấn đề là các ghi chú được đề cập bởi "Bùn" và "Frank" ở trên đều có thể đúng cũng như "Pete" (logic nghiệp vụ có thể được đưa vào mô hình hoặc bộ điều khiển theo loại hình kinh doanh logic).
Cuối cùng, lưu ý rằng MVC khác với ngữ cảnh. Ví dụ: trong các ứng dụng Android, một số định nghĩa thay thế được đề xuất khác với các định nghĩa dựa trên web (xem ví dụ này post).
Q2:
Kinh doanh logic là tổng quát hơn và (như "decyclone" được đề cập ở trên), chúng tôi có mối quan hệ sau đây giữa chúng:
quy tắc kinh doanh ⊂ logic kinh doanh
Việc đặt lớp kinh doanh của bạn trong Mô hình cho dự án MVC không có ý nghĩa.
Nói rằng ông chủ của bạn quyết định thay đổi các lớp trình bày để cái gì khác, bạn sẽ được vặn! Lớp kinh doanh phải là một hội đồng riêng biệt. Mô hình chứa dữ liệu đến từ lớp doanh nghiệp chuyển đến chế độ xem để hiển thị. Sau đó, trên bài viết ví dụ, mô hình liên kết với một lớp Person nằm trong lớp nghiệp vụ và gọi PersonBusiness.SavePerson (p); trong đó p là lớp Person. Đây là những gì tôi làm (BusinessError lớp là mất tích nhưng cũng sẽ đi trong BusinessLayer quá): 
Như một vài câu trả lời đã chỉ ra, tôi tin rằng có một số một số hiểu lầm về đa tầng vs MVC kiến trúc.
kiến trúc đa tầng liên quan đến việc phá vỡ các ứng dụng của bạn vào tầng/lớp (ví dụ trình bày, logic kinh doanh, truy cập dữ liệu)
MVC là một phong cách kiến trúc cho các lớp trình bày của một ứng dụng. Đối với các ứng dụng không tầm thường, các quy tắc nghiệp vụ/kinh doanh/truy cập dữ liệu không được đặt trực tiếp vào Mô hình, Chế độ xem hoặc Bộ điều khiển. Để làm như vậy sẽ được đặt logic kinh doanh trong lớp trình bày của bạn và do đó làm giảm tái sử dụng và bảo trì mã của bạn. Mô hình là một lựa chọn rất hợp lý để đặt logic nghiệp vụ, nhưng cách tiếp cận tốt hơn/dễ bảo trì hơn là tách lớp trình bày khỏi lớp logic nghiệp vụ của bạn và tạo lớp logic nghiệp vụ và chỉ cần gọi lớp logic nghiệp vụ từ mô hình khi cần. Lớp logic nghiệp vụ sẽ lần lượt gọi vào lớp truy cập dữ liệu.
Tôi muốn chỉ ra rằng tìm mã hỗn hợp logic kinh doanh và truy cập dữ liệu ở một trong các thành phần MVC là không phổ biến, đặc biệt nếu ứng dụng không được cấu trúc bằng nhiều tầng. Tuy nhiên, trong hầu hết các ứng dụng doanh nghiệp, bạn thường sẽ tìm thấy các kiến trúc nhiều tầng với kiến trúc MVC tại chỗ trong lớp trình bày.
Cảm ơn ví dụ. Đối với mục nhập email của quản trị viên (kiểm soát xem nó có thể bị xóa hay không), chúng tôi có thể không kiểm soát việc sử dụng bộ điều khiển của chúng tôi không? – hmthur
@mud gì nếu chúng ta chia mô hình của mình thành hai lớp khác, tức là lớp dịch vụ và kho lưu trữ ... lớp dịch vụ chịu trách nhiệm về logic nghiệp vụ và kho lưu trữ chịu trách nhiệm về lớp dữ liệu ...? – Dragon
@Mud có nghĩa là Business Logic được chứa trong bộ điều khiển? –