Khi nào nên sử dụng Windows Workflow Foundation? [đóng cửa]

Một số điều dễ thực hiện hơn chỉ bằng tay (mã), nhưng một số dễ dàng hơn thông qua WF. Dường như WF có thể được sử dụng để tạo (gần như) bất kỳ loại thuật toán nào. Vì vậy (về mặt lý thuyết) tôi có thể thực hiện tất cả logic của mình trong WF, nhưng có lẽ đó là một ý tưởng tồi để làm điều đó cho tất cả các dự án.

Trong những tình huống nào là một ý tưởng tốt để sử dụng WF và khi nào nó sẽ làm cho mọi thứ khó khăn hơn thì chúng phải như thế nào? Ưu và nhược điểm / chi phí của WF so với mã hóa bằng tay là gì?

Bạn chỉ có thể cần WF nếu bất kỳ điều nào sau đây là đúng:

1. Bạn có một quá trình lâu dài.
2. Bạn có một quá trình thay đổi thường xuyên.
3. Bạn muốn một mô hình trực quan của quá trình.

Để biết thêm chi tiết, hãy xem bài đăng của Paul Andrew: Sử dụng Windows Workflow Foundation để làm gì?

Xin đừng nhầm lẫn hoặc liên quan WF với lập trình trực quan dưới bất kỳ hình thức nào. Đó là sai và có thể dẫn đến các quyết định thiết kế / kiến ​​trúc rất xấu.

Không bao giờ. Bạn có thể sẽ hối tiếc:

• Dốc học
• Khó gỡ lỗi
• Khó bảo trì
• Không cung cấp đủ sức mạnh, tính linh hoạt hoặc tăng năng suất để biện minh cho việc sử dụng nó
• Có thể và sẽ làm hỏng trạng thái ứng dụng không thể phục hồi

Lần duy nhất tôi có thể nghĩ đến việc sử dụng WF là nếu tôi muốn lưu trữ nhà thiết kế cho người dùng cuối và có lẽ thậm chí là không.

Tin tôi đi, sẽ không có gì đơn giản, mạnh mẽ hay linh hoạt như mã mà bạn viết để làm chính xác những gì bạn cần nó làm. Tránh xa WF.

Tất nhiên, đây chỉ là ý kiến ​​của tôi, nhưng tôi nghĩ nó là một thứ tốt. :)

Mã được tạo bởi WF là khó chịu. Giá trị mà WF mang lại là sự thể hiện trực quan của hệ thống, mặc dù tôi chưa thấy gì (6-7 dự án đang hoạt động với WF mà tôi đã tham gia), nơi tôi sẽ không thích một dự án mã hóa đơn giản hơn .

Nói chung, nếu bạn không cần các tính năng theo dõi và kiên trì (mà theo tôi là các tính năng chính), bạn không nên sử dụng Workflow Foundation.

Dưới đây là những ưu điểm và nhược điểm của Workflow Foundation mà tôi thu thập được từ kinh nghiệm của mình:

Ưu điểm

• Kiên trì: Nếu bạn sẽ có nhiều quy trình chạy dài (nghĩ ngày, tuần, tháng), thì Workflows rất tốt cho việc này. Các trường hợp dòng công việc nhàn rỗi được duy trì cho cơ sở dữ liệu để nó không sử dụng hết bộ nhớ.
• Theo dõi: WF cung cấp cơ chế theo dõi từng hoạt động được thực hiện trong quy trình làm việc
• * Visual Designer: Tôi đặt nó dưới dạng *, vì tôi nghĩ rằng nó thực sự chỉ hữu ích cho mục đích tiếp thị. Là một nhà phát triển, tôi thích viết mã hơn là ghép các thứ lại với nhau một cách trực quan. Và khi bạn có một quy trình làm việc không dành cho nhà phát triển, bạn thường kết thúc với một mớ hỗn độn khó hiểu.

Nhược điểm

• Mô hình lập trình: Bạn thực sự bị hạn chế về tính năng lập trình. Hãy suy nghĩ về tất cả các tính năng tuyệt vời bạn có trong C #, sau đó quên chúng đi. Các câu lệnh một hoặc hai dòng đơn giản trong C # trở thành một hoạt động khối khá lớn. Điều này đặc biệt là một nỗi đau cho xác nhận đầu vào. Phải nói rằng, nếu bạn thực sự cẩn thận chỉ giữ logic cấp cao trong quy trình công việc và mọi thứ khác trong C #, thì đó có thể không phải là vấn đề.
• Hiệu suất: Quy trình làm việc sử dụng một lượng lớn bộ nhớ. Nếu bạn đang triển khai nhiều quy trình công việc trên máy chủ, hãy đảm bảo bạn có hàng tấn bộ nhớ. Cũng cần lưu ý rằng quy trình làm việc chậm hơn nhiều so với mã C # bình thường.
• Đường cong học tập ổn định, khó gỡ lỗi: Như đã đề cập ở trên. Bạn sẽ dành nhiều thời gian để tìm ra cách để mọi thứ hoạt động, và tìm ra cách tốt nhất để làm một cái gì đó.
• Tính không tương thích của phiên bản quy trình làm việc: Nếu bạn triển khai một quy trình công việc một cách kiên trì và bạn cần thực hiện cập nhật cho quy trình công việc, các phiên bản quy trình công việc cũ không còn tương thích. Giả sử điều này được cố định trong .NET 4.5.
• Bạn phải sử dụng biểu thức VB (.NET 4.5 cho phép biểu thức C #).
• Không linh hoạt: Nếu bạn cần một số chức năng đặc biệt hoặc cụ thể không được cung cấp bởi Workflow Foundation, hãy chuẩn bị cho rất nhiều nỗi đau. Trong một số trường hợp, nó thậm chí có thể không thể. Ai biết cho đến khi bạn cố gắng? Có rất nhiều rủi ro ở đây.
• Dịch vụ WCF XAML không có giao diện: Thông thường với dịch vụ WCF, bạn phát triển dựa trên giao diện. Với Dịch vụ WCF XAML, bạn không thể đảm bảo Dịch vụ WCF XAML đã triển khai mọi thứ trong một giao diện. Bạn thậm chí không cần xác định một giao diện. (theo như tôi biết...)

Lý do chính tôi đã tìm thấy để sử dụng nền tảng quy trình công việc là nó mang lại cho bạn bao nhiêu tiền về khả năng theo dõi và kiên trì. Thật dễ dàng để có được dịch vụ bền bỉ và chạy, điều này mang lại độ tin cậy và phân phối tải giữa nhiều phiên bản và máy chủ lưu trữ.

Mặt khác, giống như các ứng dụng biểu mẫu, các mẫu mã mà trình thiết kế quy trình công việc đẩy bạn về phía trước là xấu. Nhưng bạn có thể tránh các vấn đề bằng cách viết không có mã trong quy trình công việc và ủy thác tất cả công việc cho các lớp khác, có thể được tổ chức và đơn vị được kiểm tra một cách duyên dáng hơn quy trình công việc. Sau đó, bạn có được khía cạnh hình ảnh mát mẻ của nhà thiết kế mà không có mã spaghetti phía sau.

Cá nhân tôi không được bán trên WF. Tính hữu dụng của nó không rõ ràng đối với tôi như các công nghệ MS mới khác, như WPF hoặc WCF.

Tôi nghĩ WF sẽ được sử dụng nhiều trong các ứng dụng kinh doanh trong tương lai, nhưng tôi không có kế hoạch sử dụng nó bởi vì nó dường như không phải là công cụ phù hợp cho công việc cho các dự án của tôi.

Công ty tôi hiện đang làm việc để thành lập Windows Workflow Foundation (WF) và lý do họ chọn sử dụng nó là vì các quy tắc sẽ thường xuyên thay đổi và điều đó sẽ buộc họ phải biên dịch lại các dll khác nhau, v.v. là đặt các quy tắc trong DB và gọi chúng từ đó. Bằng cách này, họ có thể thay đổi các quy tắc và không phải biên dịch lại và phân phối lại các dll, v.v.

Windows Workflows quyến rũ các nhà quản lý CNTT không mã hóa, BA và tương tự như anh em họ BizTalk nhưng trong thử nghiệm đơn vị thực tế, gỡ lỗi và bảo hiểm mã chỉ là ba trong số nhiều cạm bẫy. Bạn có thể khắc phục một số trong số họ nhưng bạn phải đầu tư rất nhiều để đạt được điều đó trong khi với mã đơn giản, bạn chỉ cần có được điều đó. Nếu bạn thực sự có một yêu cầu lâu dài thì có lẽ bạn cần một cái gì đó tinh vi hơn. Tôi đã nghe lập luận về việc có thể bỏ các tệp xaml mới vào sản xuất mà không cần biên dịch lại các dll nhưng thành thật mà nói, thời gian mà Workflows sẽ tiêu thụ có thể được sử dụng tốt hơn để cải thiện Tích hợp liên tục của bạn đến điểm mà việc biên dịch triển khai không phải là vấn đề.

Tôi sẽ sử dụng nó trong bất kỳ môi trường nào tôi cần làm việc với quy trình công việc, tuy nhiên khi sử dụng kết hợp với K2 hoặc thậm chí SharePoint 2007, sức mạnh của nền tảng thực sự hữu ích. Khi phát triển các ứng dụng kinh doanh với chuyên gia BI, việc sử dụng nền tảng được khuyến nghị và điều này thường chỉ có liên quan để hợp lý hóa và cải thiện quy trình kinh doanh.

Đối với bản ghi WF được phát triển cùng với nhóm phát triển của K2 và K2 Blackpearl mới được xây dựng trên đỉnh WF, công cụ xử lý công việc của MOSS 2007 và WSS 3.0 cũng vậy.

Khi bạn không muốn viết thủ công tất cả các mã đó để duy trì giao diện trực quan, theo dõi và kiên trì, đó là một lựa chọn khôn ngoan để bỏ phiếu cho WF.

Tôi đã sử dụng quy trình làm việc của Windows trong nhiều tháng nay để phát triển các hoạt động tùy chỉnh và một nhà thiết kế được lưu trữ lại mà những người không phải là nhà phát triển có thể sử dụng để xây dựng quy trình công việc. WF rất mạnh nhưng nó chỉ tốt như các hoạt động tùy chỉnh được xây dựng bởi các nhà phát triển. Khi nói đến nó, một nhà phát triển sẽ phải xem xét các quy trình công việc được xây dựng bởi những người không phải là nhà phát triển để kiểm tra và gỡ lỗi nhưng từ đó họ có thể tạo ra các quy trình công việc dự thảo - thật tuyệt vời.

Hơn nữa, trong trường hợp bạn có các quy trình chạy dài, WF là một ngăn xếp công nghệ tốt để sử dụng khi bạn cần cập nhật các quy trình một cách linh hoạt - mà không phải cài đặt lại / tải xuống hoặc làm bất cứ điều gì, chỉ cần thêm các tệp XAML mới vào một thư mục và kiến ​​trúc của bạn phải thiết lập với phiên bản để loại bỏ cái cũ và sử dụng cái mới.