Nơi để đặt logic kinh doanh trong thiết kế MVC?

Tôi đã tạo một ứng dụng Java MVC đơn giản để thêm các bản ghi thông qua các biểu mẫu dữ liệu vào cơ sở dữ liệu.

Ứng dụng của tôi thu thập dữ liệu, nó cũng xác nhận nó và lưu trữ nó. Điều này là do dữ liệu đang được lấy trực tuyến từ những người dùng khác nhau. dữ liệu chủ yếu là số.

Bây giờ trên dữ liệu số được lưu trữ vào cơ sở dữ liệu (máy chủ SQL), tôi muốn ứng dụng của mình thực hiện tính toán và hiển thị kết quả. Người dùng không quan tâm đến việc tính toán được thực hiện như thế nào để chúng phải được gói gọn. Người dùng chỉ có thể xem dữ liệu được tính toán đơn giản (ví dụ: dữ liệu cột A trừ dữ liệu cột B chia cho dữ liệu cột C). Tôi biết làm thế nào để viết các thủ tục được lưu trữ cho cùng nhưng tôi muốn một ứng dụng ba lớp.

Tôi muốn dữ liệu mà tôi đưa vào cơ sở dữ liệu dưới dạng bản ghi, được thực hiện bằng cách thực hiện các tính toán trên nó. Dữ liệu gốc sẽ không bị ảnh hưởng, trong khi dữ liệu mới, tính toán sau, phải được lưu trữ dưới dạng bản ghi thực thể mới vào cơ sở dữ liệu.

Tôi nên viết mã cho tính toán nền này ở đâu? Vì nó là các quy tắc và logic nghiệp vụ, tôi có nên đặt nó trong các tệp JavaBeans mới không?

— BriskLabs Pakistan
nguồn

có thể trùng lặp với OO và Testable khi làm việc với cơ sở dữ liệu

— gnat

Câu trả lời:

Các logic kinh doanh nên được đặt trong các mô hình , và chúng ta nên nhắm đến chất béo mô hình và gầy bộ điều khiển .

Là một điểm khởi đầu, chúng ta nên bắt đầu từ logic điều khiển. Ví dụ: trên bản cập nhật , điều khiển của bạn nên trực tiếp mã của bạn để các phương pháp / dịch vụ đó mang lại những thay đổi của mình vào mô hình.

Trong mô hình, chúng ta có thể dễ dàng tạo các lớp trợ giúp / dịch vụ trong đó các quy tắc hoặc tính toán kinh doanh ứng dụng có thể được xác nhận.

Một bản tóm tắt khái niệm

Bộ điều khiển dành cho logic ứng dụng. Logic dành riêng cho cách ứng dụng của bạn muốn tương tác với "miền kiến thức" mà nó thuộc về.
Các mô hình là cho logic mà không phụ thuộc vào ứng dụng . Logic này phải hợp lệ trong tất cả các ứng dụng có thể có của "miền kiến thức" mà nó thuộc về.
Vì vậy, thật hợp lý khi đặt tất cả các quy tắc kinh doanh trong mô hình.

— EL Yusubov
nguồn

câu trả lời rõ ràng và súc tích ..

— hanzolo

@Yusubov, xin vui lòng bạn có thể giải thích cho tôi sự khác biệt giữa logic ứng dụng và logic kinh doanh

— Mohamad

@Moh, Tóm lại đây là những từ buzz để giúp mô tả các tầng công nghệ trong một ứng dụng. Logic kinh doanh về cơ bản là các quy tắc của hệ thống theo các đặc tả chức năng. Ví dụ: Đối tượng A loại B phải có C và D, nhưng không phải E. Application Logic là một đặc tả kỹ thuật, như sử dụng các máy chủ Java và OJB để duy trì cơ sở dữ liệu Oracle.

— EL Yusubov

Bạn có thể giải thích rõ hơn về những từ này:

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controll-in-php ]

— revo

Nếu tôi hiểu đúng, bài viết được đề cập đề cập đến 'logic ứng dụng' là 'logic kinh doanh'. Vì vậy, bất cứ điều gì đề cập đến logic nghiệp vụ không nên được đặt trong bộ điều khiển hoặc khung nhìn.

— EL Yusubov

Như mọi khi, nó phụ thuộc vào sự phức tạp của dự án.

Trong các ứng dụng tầm thường, nơi độ phức tạp của mô hình miền tương đối nhỏ, bạn có thể đặt logic trong các mô hình và gọi nó là một ngày.

Tuy nhiên, đối với các ứng dụng không tầm thường với các mô hình phức tạp và nhiều quy tắc kinh doanh, tốt hơn hết là tách biệt mọi thứ hơn một chút.

Nếu bạn đặt logic nghiệp vụ liên quan đến nhiều hơn một mô hình trong một mô hình, thì bạn đang giới thiệu một khớp nối chặt chẽ giữa các mô hình đó. Khi các ứng dụng tiếp tục phát triển, các mô hình này có xu hướng biến thành god models, biết quá nhiều. Và điều này sẽ nhanh chóng biến thành một mớ hỗn độn lớn khó kiểm tra và bảo trì. Vì vậy, trong trường hợp đó, có lợi khi đặt logic trong một lớp riêng biệt.

Khi quyết định về sự trừu tượng, luôn luôn tính đến sự phức tạp và mục đích ứng dụng của bạn và tránh kỹ thuật quá cao. Đối với các ứng dụng nhỏ / nhỏ, việc giới thiệu nhiều lớp hơn mức cần thiết sẽ tăng độ phức tạp thay vì giảm bớt.

Robert Martin (chú Bob) có một bài đăng blog hay về chủ đề này: Kiến trúc sạch.

— Hakan Deryal
nguồn

câu hỏi cụ thể cho MVC. logic kinh doanh phải luôn luôn trong mô hình. Bộ điều khiển chỉ là một bộ chuyển đổi.

— jgauffin

MVC là một trong những thuật ngữ quá tải nhất trong ngành. Tôi không muốn nhận được những điều kỳ quặc của thuật ngữ này, vì nó đảm bảo một cuốn sách. Chỉ là, sử dụng MVC không có nghĩa là bạn phải đặt mọi logic trong các mô hình.

— Hakan Deryal

Từ định nghĩa của Steve Burbeck (nhóm Smalltalk) :

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

. Đó là một định nghĩa bộ chuyển đổi.

— jgauffin

Nếu bạn đặt tất cả logic trong mô hình, bạn sẽ kết thúc với hàng ngàn dòng lộn xộn không thể nhầm lẫn. Đã ở đó. Không có tội khi có các lớp tiện ích và lớp dịch vụ.

— asthasr

Tôi nghĩ những gì jgauffin nhận được là câu hỏi dành riêng cho MVC. Nếu chúng tôi đồng ý xem hệ thống từ phối cảnh MVC và chỉ phối cảnh MVC, thì có, tất cả logic nghiệp vụ thuộc về "mô hình", nhưng "mô hình" có thể bao gồm nhiều lớp và lớp, bao gồm cả "lớp tiện ích" và "Một lớp dịch vụ". Nói cách khác, chúng ta sẽ không nói lớp dịch vụ là một phần của bộ điều khiển hoặc khung nhìn, do đó, sự phù hợp nhất là mô hình.

— DavidS

Đặt logic kinh doanh bên trong mô hình có thể là cách tốt nhất để đi. Bộ điều khiển nhận cuộc gọi từ ứng dụng web từ xa. Bộ điều khiển trên dịch vụ web MVC nhận cuộc gọi và chuyển hướng thực hiện đến một phương thức trong BL. Bây giờ, Logic nghiệp vụ có thể được chứa trong 'Mô hình', nhưng cũng có thể được định vị trong một số thư mục khác, 'Logic kinh doanh' . Vì vậy, không có quy tắc khó và nhanh về việc logic kinh doanh sẽ diễn ra ở đâu.

Tôi đã sử dụng một dịch vụ web được xây dựng trên MVC 3.0 và bộ chứa logic nghiệp vụ là MODEL MVC .

— Monty Python
nguồn

Tôi đồng ý. Bạn nhận được một ứng dụng linh hoạt hơn nhiều khi mô hình của bạn chỉ đơn giản là một cấu trúc dữ liệu được tác động bởi các lớp logic nghiệp vụ khác. Một ví dụ đơn giản, tôi nghĩ rằng đó là một thất bại lớn trong cách tiếp cận xác thực của ASP.NET bằng cách sử dụng các thuộc tính. Nếu tôi chú thích thuộc tính FirstName của một người với thuộc tính Bắt buộc, điều gì xảy ra nếu tôi tạo chế độ xem quản trị viên trong đó FirstName không được yêu cầu? Một lớp logic nghiệp vụ nên tiêu thụ mô hình và xác định các hành động thích hợp cho nó.

— xr280xr