Bây giờ mọi người đang nói về MVC, tôi nhận thấy rằng các quy tắc kinh doanh không được giải quyết. Trong những ngày cũ của kiến trúc 3 tầng, Các quy tắc nghiệp vụ nằm ở tầng giữa. Họ rơi vào đâu trong MVC mới?Quy tắc kinh doanh ở đâu trong MVC
Ở bàn chải đầu tiên, tôi muốn nói chúng thuộc về mô hình. Các MVC Entry on Wikipedia dường như đồng ý: "Trong MVC, mô hình đại diện cho thông tin (dữ liệu) của ứng dụng và các quy tắc kinh doanh được sử dụng để thao tác dữ liệu". Sau khi tất cả, theo 'quy tắc kinh doanh', chúng tôi có nghĩa là các thuật toán chức năng và logic mã hóa tên miền mà ứng dụng của bạn tham gia, trái ngược với logic liên quan đến đầu vào/đầu ra. Các logic liên quan đến kinh doanh cốt lõi này không - hoặc không nên thay đổi dựa trên những gì đang được hiển thị cho người dùng (đó là miền của View) hoặc đầu vào của người dùng (mà chủ yếu được Bộ điều khiển nhận). Theo kinh nghiệm của tôi, việc hỏi loại câu hỏi này đã rất tiết lộ trong quá trình phát triển phần mềm: chúng tôi đã tìm thấy một số lượng lớn những thứ được coi là 'quy tắc kinh doanh' của một số người, nhưng hóa ra lại là thứ khác. Nếu nó không phải là một quy tắc kinh doanh thực sự, nó có thể không thuộc về mô hình.
Mô hình mặc dù KHÔNG được trong dự án MVC và nó không nên có phụ thuộc vào bất kỳ công nghệ giao diện người dùng cụ thể nào. – Andy
Một trích dẫn từ một Wikipedia Article:
MVC thường thấy trong các ứng dụng web, nơi xem là trang HTML thực tế, và bộ điều khiển là mã mà tập hợp dữ liệu động và tạo ra các nội dung trong HTML. Cuối cùng, mô hình được thể hiện bằng nội dung thực tế, thường được lưu trữ trong cơ sở dữ liệu hoặc trong các nút XML, và quy tắc kinh doanh chuyển đổi nội dung đó dựa trên hành động của người dùng.
Đó không phải là MVC. MVC là về tổ chức mã. Tất cả các trang web động sẽ là MVC theo định nghĩa của bạn. –
Có lý do nào khiến bạn không thể kết hợp MVC và Ntier không? Ứng dụng của chúng tôi thực hiện điều đó. Các bộ điều khiển của chúng tôi được sử dụng để xác thực dữ liệu và quyết định các lớp Business nào cần thực hiện.
OurApp.Web - Dự án MVC Asp.net
OurApp.Business - Kinh doanh lớp Thư viện
OurApp.DataAccess - Data Layer Thư viện
OurApp.Entities - Về cơ bản tất cả các 'mô hình' được chia sẻ bởi tất cả các lớp
Tôi thích cách tiếp cận này. Thật không may, tôi nghĩ rằng nhiều khuôn khổ web làm cho bước nhảy vọt này trở nên khó chịu. Tại một số điểm, bạn có thể cần các đối tượng trợ giúp trong lớp nghiệp vụ của bạn mà không nhất thiết phải tương ứng với bất kỳ bảng cơ sở dữ liệu/lưu trữ liên tục nào - thứ mà mọi kiểu mô hình mà tôi thấy dường như là một điều cơ bản. Tại thời điểm đó bạn tự hỏi, tôi cũng đặt mã này ở đâu? – Koobz
Quy tắc kinh doanh luôn tồn tại trong mô hình. Mô hình là bit mà bạn có thể sử dụng lại với giao diện người dùng hoàn toàn khác. Quan điểm rõ ràng là hoàn toàn phụ thuộc vào các lựa chọn giao diện người dùng và bộ điều khiển phải lấy dữ liệu từ mô hình và nói cho khung nhìn hiển thị nó.
Đặt logic nghiệp vụ vào chế độ xem không tốt vì nó gắn kết cấu trúc với bản trình bày.
Đưa logic nghiệp vụ vào bộ điều khiển là không tốt vì nó chia tách miền doanh nghiệp của bạn giữa dữ liệu được duy trì bởi mô hình và các quy tắc trong bộ điều khiển.
Lý do bạn không bao giờ thấy địa chỉ MVC "Quy tắc kinh doanh" là MVC theo và lớn là mẫu trình bày. Nó tập trung vào cách cấu trúc ứng dụng của bạn. Mô hình, ví dụ, có thể được coi là một mô hình trình bày. Mô hình ứng dụng của bạn, chế độ xem sau đó sẽ hiển thị.
Tuy nhiên, để tạo mô hình trình bày, bạn thường cần truy cập vào các mô hình miền nơi tất cả logic nghiệp vụ của bạn hoạt động. Tại thời điểm đó, MVC không ra lệnh nơi mã đó thể chất sống. Có phải trên một tầng khác không? MVC không quan tâm.
Đây có phải là câu trả lời được chấp nhận –
Các bạn sai quy tắc kinh doanh trong bộ điều khiển chứ không phải mô hình ...
bất kỳ đối số nào không? – Kamarey
Nhận xét này chỉ đơn giản là WRONG. Bộ điều khiển là một phần kỹ thuật của ứng dụng, phối hợp các luồng dữ liệu và kích hoạt các hành động trong mô hình và khung nhìn. Trong một ứng dụng PC điển hình, bộ điều khiển có liên quan đến các sự kiện chuột, tổ hợp phím và các loại tương tự. –
Quy tắc kinh doanh phải nằm trong mô hình, KHÔNG phải bộ điều khiển. Bộ điều khiển và khung nhìn là một phần của lớp trình bày.
Mô hình này đại diện cho các tổ chức và chức năng của miền ..
Bộ điều khiển chỉ đơn thuần là một người quản lý đã dành đầu vào người sử dụng và yêu cầu, thực hiện hành động trong/trên mô hình và lập bản đồ đó để xem trong lớp trình bày. Bộ điều khiển cũng không chỉ là bộ trung gian, bộ điều khiển OR có thể hoạt động theo mô hình.
Tôi nghĩ rằng rất nhiều người ngầm nghĩ rằng mô hình là "mô hình cơ sở dữ liệu", đó là lý do tại sao các quy tắc kinh doanh dường như không có chỗ. Nếu thay vào đó, bạn thấy mô hình như là một mô phỏng của một cái gì đó từ thế giới thực, thì rõ ràng là các quy tắc nghiệp vụ là một phần của mô hình như là dữ liệu mà chúng thao tác. –
Tôi nghĩ vấn đề là vấn đề về định nghĩa. Dường như với tôi rằng logic để trình bày các màn hình theo thứ tự cần thiết là một vấn đề điều khiển và tôi đã thấy một số dự án sử dụng một công cụ quy tắc để xác định thứ tự và những gì được yêu cầu đầu vào từ người dùng. Điều này không giống như quy tắc kinh doanh imho.
Tôi tin rằng OP đang nói về logic kinh doanh thuộc về mô hình. –
Đây là câu hỏi được đăng cổ, nhưng tôi thích kho lưu trữ quy tắc hoàn toàn độc lập với bất kỳ phần nào của ứng dụng. Nhiều ứng dụng, nhiều triển khai của một tầng nghiệp vụ, sẽ có thể truy cập một kết xuất tĩnh của kho lưu trữ quy tắc nghiệp vụ. Các quyết định tách đơn giản như điều này làm cho việc di chuyển từ máy tính để bàn -> web chẳng hạn, tầm thường. Trong kiến trúc của tôi, View -> Model -> Controller -> Business Tier -> Rules Repository, tức là bộ điều khiển truy cập dữ liệu thô như được trình bày bởi tầng/lớp nghiệp vụ, đưa nó vào mô hình làm mát nó thành một thể hiện biểu mẫu và chế độ xem hiển thị một cách thụ động nó. Tầng nghiệp vụ, có thể sử dụng lại được trên bất kỳ định dạng bản trình bày nào, sẽ có các quy tắc rõ ràng và quyền truy cập vào một hệ thống con với các quy tắc ngầm định. Theo thiết kế, mỗi thành phần là không biết gì về các chi tiết của một thành phần bên trên nó.
Vì vậy? Quicksort là 46 tuổi và vẫn đang được sử dụng. Điều quan trọng là nó hoạt động rất tốt. –
Tôi nhận thấy điều tương tự cách đây vài năm. Nó có vẻ như ngay sau khi tôi học được nó, nó bắt đầu xuất hiện ở mọi nơi tôi nhìn. –