Các ứng dụng dựa trên quy tắc có khả năng mở rộng và năng động cao?

Đối với một ứng dụng doanh nghiệp lớn, mọi người đều biết rằng có thể điều chỉnh để thay đổi là một trong những khía cạnh quan trọng nhất của thiết kế. Tôi sử dụng một cách tiếp cận dựa trên quy tắc rất nhiều thời gian để đối phó với việc thay đổi logic kinh doanh, với mỗi quy tắc được lưu trữ trong một DB. Điều này cho phép thay đổi dễ dàng được thực hiện mà không cần đi sâu vào các chi tiết khó chịu. Bây giờ vì C # không thể Eval ("foo (bar);") điều này được thực hiện bằng cách sử dụng các chuỗi được định dạng được lưu trữ trong các hàng sau đó được xử lý trong JavaScript khi chạy. Điều này hoạt động tốt, tuy nhiên, nó kém thanh lịch và sẽ không thú vị nhất cho bất kỳ ai khác nhận được một khi nó trở thành di sản.

Có một giải pháp thanh lịch hơn cho điều này? Khi bạn có hàng ngàn quy tắc thay đổi khá thường xuyên, nó sẽ trở thành một con gấu thực sự, nhưng điều này không thể là vấn đề hiếm gặp mà ai đó không nghĩ ra cách nào tốt hơn để làm điều này. Bất kỳ đề xuất? Là phương pháp hiện tại này có thể phòng thủ? Các lựa chọn thay thế là gì?

Chỉnh sửa: Chỉ cần làm rõ, đây là một ứng dụng doanh nghiệp lớn, vì vậy cho dù giải pháp nào hoạt động, sẽ có rất nhiều người liên tục duy trì các quy tắc và dữ liệu của nó (khoảng 10). Ngoài ra, dữ liệu thay đổi thường xuyên đủ để nói rằng một số loại hệ thống máy chủ tập trung về cơ bản là bắt buộc.

Tôi sẽ sử dụng WF hoặc Drools nếu bạn đang cố gắng tạo ra một sự trừu tượng mà những người không phải lập trình viên có thể làm việc để phát triển các quy tắc kinh doanh. Tuy nhiên, nếu bạn giao dịch với các lập trình viên hơn là sự trừu tượng của WF thì không đáng để bạn mất thời gian để phát triển giải pháp, tôi không thấy giá trị gia tăng cho khoản đầu tư của mình.

Cơ sở dữ liệu là một cách tốt để duy trì các quy tắc có thể thay đổi nhiều, nhưng hãy để tôi đề xuất một giải pháp thay thế khả thi (không nhất thiết phải tốt hơn, nhưng thay thế).

1) Phân tách logic nghiệp vụ thành lớp riêng (dll) - trừu tượng hóa cách bạn gọi nó bằng một số giao diện (xem mô hình chiến lược và quan sát viên), tức là IRuleEvaluator.Evaliated (chuỗi myParams).

2) Bây giờ bạn có thể tạo các lớp riêng biệt cho từng quy tắc (nếu cần) và các bài kiểm tra đơn vị đi kèm.

3) Bây giờ đối với Pièce de résistance, hãy kết nối mọi thứ phía sau hậu trường trong một thùng chứa IOC - bản thân dll và bộ đánh giá quy tắc. Bằng cách này, trình đánh giá quy tắc của bạn được xây dựng thông qua cấu hình khi chạy - không có gì được mã hóa cứng cùng nhau.

Cách tiếp cận này rất năng động (có thể quá năng động đối với một số thị hiếu) - nó sẽ cho phép bạn có các bài kiểm tra đơn vị riêng biệt thực tế cho tất cả các quy tắc của bạn. Nếu bạn cần triển khai lại hoặc thay đổi quy tắc, bạn có thể bỏ DLL mới, thay đổi tệp cấu hình IOC, khởi động lại và xác minh - hoặc khôi phục thay đổi nếu có gì đó không đúng - mà không cần sửa đổi mã lõi của bạn (giống như một cơ sở dữ liệu). Và không giống như một cơ sở dữ liệu, nó sẽ giữ logic và mã ứng dụng dưới một ô, thay vì một nửa được viết bằng C # và một nửa bằng SQL.

Có hai trường hợp quy tắc tôi đã thấy. Trong hầu hết các trường hợp, bản thân quy tắc không biến động (gần như cố định) nhưng dữ liệu về quyết định được đưa ra có thể được thay đổi bởi người dùng doanh nghiệp. Trong trường hợp này, các mẫu thiết kế đơn giản để gói gọn mỗi quy tắc với việc đọc dữ liệu tham chiếu từ DataBase thường là đủ. Sau đó cung cấp một lối vào để thay đổi dữ liệu tham chiếu quy tắc.

Các trường hợp khác trong đó logic quy tắc có thể được thay đổi linh hoạt. Một cách tiếp cận sẽ là sử dụng IronPython hoặc các ngôn ngữ động khác (trong .Net 4) để thực hiện các quy tắc và tải chúng một cách linh hoạt tại thời điểm thực hiện. Đây là một sự thỏa hiệp vì bạn vẫn sẽ yêu cầu các lập trình viên thay đổi các quy tắc.

Nếu bạn thực sự muốn các quy tắc có thể được chỉnh sửa bởi người dùng doanh nghiệp thì việc tạo DSL cho miền doanh nghiệp của bạn là một cách tiếp cận được thực hiện. Đây là một công việc phức tạp mặc dù.

Cuối cùng, sử dụng Workflow hoặc BizTalk có thể giúp nếu các quy tắc phù hợp với các mẫu chuyển đổi / phối hợp.

Nếu bạn đang thiết kế một ứng dụng "dựa trên quy tắc" có khả năng mở rộng cao, trong đó các quy tắc phải chịu sự thay đổi thường xuyên từ doanh nghiệp thì hãy xem xét các sản phẩm BRMS hàng đầu thị trường như: 1. IBM WODM 2. FICO BLAZE Advisor 3. Dropols (mã nguồn mở)

Tôi đã làm việc trên các ứng dụng thương mại lớn với cách tiếp cận BRMS giúp chúng có khả năng mở rộng cao và dễ bảo trì và cũng làm cho chúng rất linh hoạt với thời gian ngừng sản xuất ZERO. Nó làm cho kinh doanh hạnh phúc. :)

Tôi giả sử bạn không hoàn toàn đề cập đến các hoạt động phía máy khách và đang ở .Net kể từ khi bạn đề cập đến c # ...

Nếu bạn ở khung 4, bạn có DLR (thời gian chạy ngôn ngữ động) hoặc trên bất kỳ khung nào nếu bạn đang lưu trữ các quy tắc trong sql, bạn cũng có thể xử lý chúng ở đó hoặc bạn luôn có thể sử dụng linq động trong> 3 khung hoặc viết các hàm khác nhau như các hội đồng có thể được tải theo tên trong thời gian chạy thông qua tải lắp ráp.

Không phải tất cả chúng đều thanh lịch trong nhiều trường hợp, nhưng tôi đã phải sử dụng tất cả chúng.

Một điều đáng chú ý là Windows Workflow Foundation , có thể được sử dụng cùng với ASP.NET nhưng sẽ chạy ở phía máy chủ (vì vậy nó có thể không áp dụng được cho những gì bạn đang làm). Ở vùng đất Java có jBPM (quản lý quy trình kinh doanh) cũng chạy ở phía máy chủ.

Vì các giải pháp đó có thể không phù hợp với hóa đơn cho bạn , điều tốt nhất nên làm là thực hiện các quy tắc kinh doanh đó theo mã cũ (sử dụng javascript, C # hoặc bất cứ điều gì tốt nhất cho công việc) và hy vọng rằng mã lập trình sẽ phải được cập nhật khi thay đổi thiết kế xảy ra. Sử dụng các mẫu thiết kế hướng đối tượng sẽ làm cho mã dễ dàng mở rộng. Nếu bạn viết mã tốt, nỗ lực cần thiết để thay đổi nó trong tương lai sẽ là tối thiểu.

Nếu quy tắc của bạn là tất cả của một hình thức

if <condition>
then <action>
[else <action]

Bạn có thể sử dụng Drools.NET hoặc một triển khai Rete khác như iLog.