Quy tắc kinh doanh động trong ứng dụng web

Question

Chúc mừng!

Làm việc trên một dự án dựa trên web là các quy tắc kinh doanh và logic cần được khách hàng tùy chỉnh. Tôi muốn làm điều này mà không cần phải biên dịch lại ứng dụng mỗi khi chúng tôi đăng ký một ứng dụng khách mới trên hệ thống. Các kiến ​​trúc mà tôi đã phác thảo cho đến nay là:

1. Quy trình làm việc: Tạo luồng công việc động và lưu chúng vào cơ sở dữ liệu.
2. Phản ánh: Tạo giao diện quy tắc nghiệp vụ và sử dụng phản chiếu để tải lắp ráp ứng dụng khách tùy chỉnh.
3. Động cơ quy tắc nghiệp vụ thực sự
4. Triển khai IOC Container như bản đồ cấu trúc. [zaff: đã thêm 6/4]

Bạn đã bao giờ triển khai bất kỳ điều gì tương tự như vậy chưa? Nếu vậy, kinh nghiệm của bạn là gì? Và cuối cùng là có một giải pháp khác mà tôi nên khám phá?

Cảm ơn sự giúp đỡ của bạn !!

Answer 1

Tôi đã triển khai hầu hết các phương pháp bạn đề cập. Câu trả lời có thể phụ thuộc vào nhiều yếu tố.

Vai trò khách hàng nào sẽ thực hiện thay đổi đối với quy tắc kinh doanh (ví dụ: nhà phân tích kinh doanh, nhà phát triển, người dùng điện, v.v.)? Hỗ trợ có ý nghĩa cho các nhà phân tích kinh doanh có thể yêu cầu một công cụ quy tắc với các quy tắc bên ngoài trong một db và một UI có thể sử dụng được.Hỗ trợ có ý nghĩa cho các nhà phát triển có thể đơn giản như tận dụng một cái gì đó như MEF (http://www.codeplex.com/MEF).

Bạn cũng có thể cần phải thay đổi quy tắc kinh doanh và yêu cầu hoạt động liên quan đến loại nào (ví dụ: quy trình lưu trữ vẫn đang chạy, tải miền ứng dụng ok, v.v.). Một lựa chọn tốt có thể yêu cầu một số suy nghĩ cẩn thận về khả năng so với nhu cầu trong tương lai.

Answer 2

Bạn có thể thực hiện quy tắc kinh doanh theo hướng dữ liệu, như this. Cây quyết định cũng có thể là một cách tốt để đi.

Bạn cũng có thể nghĩ về lập trình hướng-khía cạnh như một cách để triển khai quy tắc kinh doanh.

Cảnh báo duy nhất của tôi với công cụ quy tắc cảm ứng Rete là các bộ quy tắc phải được giữ nhỏ và gần với các đối tượng sử dụng chúng. Nếu bạn có thể đóng gói hành vi của một đối tượng trong một công cụ quy tắc là một phần của trạng thái của nó, thì tốt hơn. Tôi không quan tâm đến giải pháp "doanh nghiệp" đưa hàng nghìn quy tắc vào một công cụ quy tắc đơn lẻ trở thành sự phụ thuộc cho mọi phần của doanh nghiệp.

Answer 3

Đây có thể không phải là cách tiếp cận tốt nhất, nhưng công ty của tôi đã triển khai tùy chọn # 2 của bạn trong một số trường hợp, với thành công. Chúng tôi về cơ bản cấu hình khách hàng trong một cơ sở dữ liệu hoặc tập tin cấu hình, và cho mỗi khách hàng, sẽ có một bảng tra cứu lưu trữ một tên lớp để gọi cho bất kỳ hoạt động kinh doanh để thực hiện. Khi mã nhận được yêu cầu cho máy khách A, nó tìm kiếm lớp để sử dụng và tạo ra nó và thực hiện nó thông qua sự phản chiếu.

Tôi không phải là một fan hâm mộ lớn về việc đưa những thứ liên quan đến mã trong cơ sở dữ liệu, nhưng nó thực sự hoạt động tốt và không quá phức tạp trong trường hợp này.

Answer 4

Tôi thích WF, nhưng nếu bạn đã xem nó và quyết định bạn muốn một cái gì đó khác nhau, bạn nên xem K2. Ngoài ra, BizTalk có hỗ trợ BRE.

Answer 5

Tôi đã tạo một công cụ quy tắc động dựa trên mã nguồn mở .NET Business Rule Engine sau đây NxBRE. Tôi đã sử dụng công cụ Flow làm ví dụ chính cho động cơ quy tắc động của mình.

Tôi đã sử dụng cùng một kiến ​​trúc được đề cập trong câu hỏi của bạn.

Answer 6

Tôi đề nghị một sự kết hợp của 1 và 3.

Nhưng tôi không lưu trữ các quy trình làm việc trong một cơ sở dữ liệu, lưu trữ nó là một cây quyết định hoặc quy tắc dòng chảy (như chúng tôi gọi họ).

Thay đổi quy trình làm việc để phù hợp với một khách hàng cụ thể hoặc liên kết chúng với tiểu sử của họ là một công việc đơn giản khi bạn có công cụ trực quan, theo hành động, chẳng hạn như Visual Rules. Ngoài ra còn có rất nhiều lợi ích khi có nhà phân tích kinh doanh hoặc người hỗ trợ của bạn thực hiện thay đổi đó mà không phải điều chỉnh mã.

Ngoài ra, không yêu cầu nào trong số các yêu cầu này đòi hỏi phải có một công cụ AI phức tạp như RETE và hội thảo-Logic tuần tự là tốt nhất.