Có thể logic kinh doanh không len lỏi vào xem?

Tôi đã phát triển cho một số dự án ứng dụng web trong 3 năm qua, cả cá nhân và tại nơi làm việc và dường như tôi không thể biết liệu ít nhất có thể một số logic kinh doanh không kết thúc trong lớp xem của ứng dụng hay không.

Trong hầu hết các trường hợp, sẽ có các vấn đề như "Nếu người dùng đã chọn tùy chọn x thì ứng dụng phải cho phép anh ta cung cấp thông tin cho y, nếu không thì anh ta nên cung cấp thông tin z". Hoặc thực hiện một số thao tác AJAX sẽ áp dụng một số thay đổi cho mô hình nhưng KHÔNG cam kết chúng cho đến khi người dùng yêu cầu rõ ràng như vậy. Đây là một số vấn đề đơn giản nhất mà tôi gặp phải và tôi không thể hiểu làm thế nào có thể tránh được logic phức tạp trong chế độ xem.

Hầu hết các cuốn sách tôi đã đọc mô tả MVC thường trình bày một số ví dụ rất nhỏ, như các thao tác CRUD chỉ cập nhật dữ liệu trên máy chủ và hiển thị chúng, nhưng CRUD không phải là trường hợp trên hầu hết các ứng dụng phong phú.

Có thể đạt được một quan điểm không có logic kinh doanh nào không?

Có thể đạt được một quan điểm không có logic kinh doanh nào không?

Tôi thấy đây là một câu hỏi khó trả lời. (Câu hỏi kích thích tư duy!)

Về mặt lý thuyết, có, tùy thuộc vào những gì chúng ta định nghĩa là logic kinh doanh. Trong thực tế, sự tách biệt nghiêm ngặt trở nên khó khăn hơn rất nhiều, và thậm chí có thể không mong muốn.

Tách biệt các mối quan tâm là một cách tuyệt vời để suy nghĩ về việc xây dựng phần mềm: nó cung cấp cho bạn các ý tưởng về nơi đặt mã và nó cung cấp cho các nhà bảo trì một ý tưởng tốt về nơi tìm mã. Tôi sẽ lập luận rằng về cơ bản con người không thể xây dựng phần mềm hoạt động mà không có sự lo lắng. Chúng tôi cần điều này.

Nhưng, như với tất cả mọi thứ, có sự đánh đổi. Vị trí khái niệm tốt nhất có thể không phải là vị trí tốt nhất vì những lý do khác. Có thể có quá nhiều tải trên máy chủ web của bạn, vì vậy bạn thêm một số javascript vào các trang web của mình để bắt lỗi dễ dàng trước khi chúng tấn công máy chủ của bạn; bây giờ bạn có một số logic kinh doanh trong quan điểm của bạn.

Bản thân quan điểm, không có giá trị nếu không có logic kinh doanh. Và để có hiệu quả trong việc sử dụng và hiển thị, mặc nhiên hoặc rõ ràng, chế độ xem sẽ có một số kiến ​​thức về các quy trình kinh doanh đang diễn ra đằng sau nó. Chúng ta có thể hạn chế lượng kiến ​​thức đó và chúng ta có thể loại bỏ các phần của nó, nhưng những cân nhắc thực tế thường sẽ buộc chúng ta phải 'phá vỡ' mối quan tâm.

Tôi thường làm điều này: nếu người dùng đã chọn tùy chọn x, chế độ xem sẽ gọi

controller->OptionXChanged()

Sau đó, bộ điều khiển kích hoạt y trên khung nhìn:

view->SetEnableInfoY(True) // suppose False=SetDisable

Khung nhìn thông báo cho bộ điều khiển về những gì xảy ra mà không quyết định bất cứ điều gì.

Tôi đặt câu hỏi liệu các ví dụ bạn mô tả có thực sự logic kinh doanh không. Các ví dụ bạn mô tả là các hoạt động có thể được thực hiện trên hệ thống. Đó là cách bạn chọn để trình bày các lựa chọn cho người dùng có thể mang lại vẻ ngoài mà bạn đang thực hiện logic kinh doanh trong chế độ xem.

Từ điểm thuận lợi "Xem", nó chỉ cung cấp InfoY hoặc InfoZ cho hệ thống. Chỉ vì việc triển khai UI của bạn đang thực hiện một số cập nhật động dựa trên lựa chọn của nhà điều hành (ví dụ: bật InfoY hoặc InfoZ) không tạo ra chức năng logic kinh doanh. Nó thực sự xem logic thực hiện. Bạn rất có thể chỉ đơn giản là cung cấp cho nhà điều hành một lựa chọn để nhập InfoY hoặc InfoZ mà không cần toàn bộ điều cho phép. Trong bối cảnh đó, bạn vẫn sẽ xem nó là logic kinh doanh chứ? Nếu không, thì áp dụng tương tự cho việc kích hoạt / vô hiệu hóa các trường thông tin.

Tương tự với ví dụ cam kết. Đây là 2 hoạt động riêng biệt mà hệ thống yêu cầu để hoạt động đúng. Chế độ xem của bạn phải có thể bắt đầu các hành động phù hợp để thực hiện chức năng mong muốn. Có biết làm thế nào để sử dụng hệ thống của bạn có nghĩa là logic kinh doanh bị rò rỉ thông qua? Tôi có thể thấy làm thế nào ai đó có thể nói đồng ý nhưng nếu bạn tin theo cách đó thì thực tế là không có thứ gọi là logic kinh doanh khỏi bất cứ thứ gì. Bạn phải biết những gì hệ thống đang làm / làm việc với để hoàn thành bất cứ điều gì có ý nghĩa. Nếu không, sẽ rất dễ dàng để tạo một Chế độ xem và Trình điều khiển chung duy nhất hoạt động với mọi ứng dụng MVC có thể hiểu được. Mà chúng ta biết là không thể.

Tóm lại, tôi nghĩ định nghĩa về logic kinh doanh của bạn không giống với định nghĩa của người khác.

Tôi làm việc theo cách này (Struts2 + Hibernate):

My Struts Action chỉ chịu trách nhiệm hiển thị thông tin trên trình duyệt web. Không suy nghĩ.

Người dùng -> Hành động -> Dịch vụ -> Kho lưu trữ -> Truy cập dữ liệu

Hoặc là:

Tôi muốn xem -> Cách xem -> Phải làm gì -> Cách nhận -> Nơi nhận

Vì vậy, trong lớp đầu tiên (khung nhìn) tôi có một cái gì đó như:

public String execute ()   {
    try {
        CourseService cs = new CourseService();
        Course course = cs.getCourse(idCourse);
    } catch (NotFoundException e) {
        setMessageText("Course not found.");
    } catch (Exception e) {

    }
    return "ok";
}

Như bạn thấy, "quan điểm" của tôi không nghĩ gì. Đó là yêu cầu một dịch vụ (để quản lý các khóa học) một khóa học cụ thể. Dịch vụ đó có thể làm nhiều thứ hơn nữa, như báo cáo, seraches, v.v. Kết quả luôn là một danh sách hoặc một đối tượng cụ thể (như ví dụ). Các dịch vụ là máy thật, áp dụng các quy tắc và truy cập Kho lưu trữ (để quản lý dữ liệu).

Vì vậy, nếu tôi đặt Dịch vụ, Kho lưu trữ và DAOS của mình vào các thư viện khác nhau, tôi có thể sử dụng nó ngay cả trong chương trình dựa trên văn bản hoặc hệ thống máy tính để bàn dựa trên Window mà không thay đổi gì.

Dịch vụ biết phải làm gì, nhưng không biết cách hiển thị. Khung nhìn biết cách hiển thị, nhưng không biết phải làm gì. Tương tự với Dịch vụ / Kho lưu trữ: Dịch vụ gửi và yêu cầu dữ liệu, nhưng không biết dữ liệu ở đâu và làm thế nào để lấy nó. Kho lưu trữ "tạo thành" dữ liệu thô cho các đối tượng để dịch vụ có thể làm việc với.

Nhưng Kho lưu trữ không biết gì về cơ sở dữ liệu. Loại cơ sở dữ liệu (MySQL, PostgreSQL, ...) liên quan đến DAO.

Bạn có thể thay đổi DAO nếu bạn muốn thay đổi cơ sở dữ liệu và nó không được ảnh hưởng đến các lớp trên. Bạn có thể thay đổi Kho lưu trữ nếu bạn muốn cập nhật quản lý dữ liệu của mình, nhưng điều này không được ảnh hưởng đến DAO và các lớp trên. Bạn có thể thay đổi Dịch vụ nếu bạn muốn thay đổi logic của mình, nhưng điều này không được gây rối với các lớp bên trên cũng như bên dưới.

Và bạn có thể thay đổi bất cứ điều gì trong chế độ xem, ngay cả công nghệ (web, máy tính để bàn, văn bản) nhưng điều này không được ngụ ý trong bất cứ điều gì bên dưới.

Logic kinh doanh là Dịch vụ. Nhưng làm thế nào để tương tác với điều này là để xem. Nút nào để hiển thị bây giờ? Người dùng có thể thấy liên kết này? Hãy nghĩ rằng hệ thống của bạn là một chương trình dựa trên bảng điều khiển: bạn phải từ chối nếu người dùng sai chọn #> myprogram -CourseService -option=getCourse -idCourse=234hoặc dừng anh ta để nhấn các phím để viết lệnh này?

Nói chuyện trong các hệ thống dựa trên web (Struts + JavaEE) Tôi có gói điều khiển GUI riêng. Trong chế độ xem Hành động tôi cung cấp cho người dùng đã đăng nhập và lớp cung cấp cho tôi các nút (hoặc bất kỳ yếu tố giao diện nào tôi muốn).

                <div id="userDetailSubBox">
                    <c:forEach var="actionButton" items="${actionButtons}" varStatus="id">
                        ${actionButton.buttonCode}
                    </c:forEach>
                </div>

Và

private List<ActionButton> actionButtons;

Hãy nhớ để điều này ra khỏi các dịch vụ. Đây là thứ XEM. Giữ nó trong các hành động Struts. Bất kỳ tương tác giao diện nào cũng phải tách biệt hoàn toàn với mã doanh nghiệp thực, vì vậy nếu bạn chuyển hệ thống của mình, sẽ dễ dàng cắt giảm những gì bạn sẽ không cần nữa.

Trong hầu hết các trường hợp, sẽ có các vấn đề như "Nếu người dùng đã chọn tùy chọn x thì ứng dụng phải cho phép anh ta cung cấp thông tin cho y, nếu không thì anh ta nên cung cấp thông tin z"

Đó là logic cho mô hình, không phải khung nhìn. Nó có thể là một "mô hình xem", được tạo riêng để hỗ trợ UI, nhưng nó vẫn là mô hình logic. Trình tự điều khiển là:

• Bộ điều khiển đính kèm một trình xử lý để xem các sự kiện
• View đính kèm một trình xử lý cho các sự kiện mô hình
• Người dùng chọn tùy chọn X.
• Chế độ xem làm tăng sự kiện "Tùy chọn X được chọn"
• Trình điều khiển nhận sự kiện và gọi model.selectOptionX ()
• Mô hình đưa ra một sự kiện "Trạng thái mô hình đã thay đổi"
• Khung nhìn nhận được sự kiện thay đổi mô hình và cập nhật khung nhìn để khớp với trạng thái mới: inputY.enable(model.yAllowed()); inputZ.enable(model.zAllowed());

UI View Controller Model |.checkbox X checked.> | | | | | .. X selected ...>| | | | |-----> set X ------->| | | | | | |< .............state changed ............| | | | | | |-------------- Get state --------------->| | | | | | |<----------- new state ------------------| | <-- UI updates ------| Đây là mô hình MVC cổ điển. Có thể kiểm tra hoàn toàn logic mô hình tách biệt với UI. Bộ điều khiển và khung nhìn rất mỏng và dễ kiểm tra.

=== Đáp lại Dunk ===

Mô hình trong mô hình UI UI (thường) không phải là mô hình đối tượng kinh doanh. Nó chỉ là mô hình cho trạng thái UI. Trong một ứng dụng máy tính để bàn, nó có thể chứa các tham chiếu đến nhiều mô hình kinh doanh. Trong ứng dụng Web 2.0, đây là lớp Javascript chứa trạng thái UI và giao tiếp qua AJAX đến máy chủ. Điều rất quan trọng là có thể viết các bài kiểm tra đơn vị thực hành của mô hình trạng thái UI, vì đó là nơi tìm thấy hầu hết các lỗi UI. Khung nhìn và bộ điều khiển phải là đầu nối rất mỏng.

Một logic nghiệp vụ giống như vậy If X then return InfoType.Y, sau đó UI sẽ hiển thị các trường dựa trên kết quả được trả về bởi tên miền.

// Controller method pseudocode
option changed routine

    get selected option

    get required info type from domain routine based on selected option

    display fields based on required info type

Nếu UI yêu cầu logic nghiệp vụ, sau đó ủy quyền lựa chọn cho miền. UI sẽ chỉ đơn giản là hành động theo quyết định.

Nếu người dùng đã chọn tùy chọn x thì ứng dụng phải cho phép anh ta cung cấp thông tin cho y, nếu không thì anh ta nên cung cấp thông tin z ".

Có những đầu vào có giá trị yêu cầu dựa trên điều kiện. Trong hầu hết các môi trường GUI, có rất nhiều lựa chọn về cách xử lý các đầu vào đặc biệt là thời gian. Tùy chọn đã chọn (trong trường hợp này là x) cần được xử lý, vì vậy hãy gửi nó đến bộ điều khiển. Gửi nó khi người dùng rời khỏi trường đầu vào. Đợi cho đến khi họ nhấp vào đối tượng khác hoặc nhấn lưu. Không quan trọng với logic kinh doanh. Bằng cách này hay cách khác, bộ điều khiển sẽ đưa ra quyết định và cần nói với quan điểm, "y là bắt buộc".

Cách xem diễn giải hoặc thực hiện điều này không thực sự quan trọng từ quan điểm logic kinh doanh. Làm cho ya yêu cầu trường. Có một cửa sổ bật lên hoặc bắn ra một khẩu súng thần công và bảo người dùng nhập y hoặc chỉ bướng bỉnh và đừng để người dùng nghèo làm bất cứ điều gì cho đến khi cô ấy nhận ra điều này.

Và chỉ cần nghĩ rằng, tất cả những điều này có thể đã xảy ra do bộ điều khiển đã cố lưu và không đưa vào một giá trị cho một trường bắt buộc trong cơ sở dữ liệu và hoàn toàn phản hồi lỗi cơ sở dữ liệu. Nó không quan trọng khi có liên quan.

Một cái gì đó như một giá trị bắt buộc hoặc giới hạn cho một đầu vào có thể được xử lý ở nhiều nơi. Nếu bạn "chỉ" giải quyết nó trong chế độ xem, nhiều nhà phát triển sẽ thấy đây là một vấn đề khi có thể có nhiều giao diện người dùng. Đây là lý do tại sao logic kinh doanh có thể được tạo và kiểm tra mà không cần nhiều giao diện người dùng hoặc thậm chí là cơ sở dữ liệu. Bạn thậm chí không cần phải có một trang web.