.NET WF4: Có nên ở giữa mọi thứ không?

Question

Tôi đang làm việc trên một kiến ​​trúc mới về bản chất là một ứng dụng cộng tác n-tier (không phải là doanh nghiệp, chỉ là một dự án nhỏ với tiềm năng phát triển đáng kể), nơi tôi đã cố gắng kỷ luật bản thân mình để sử dụng IoC và mức độ, TDD, và tôi tự hỏi, nói chung, cho dù đó là khôn ngoan hơn chỉ logic dòng công việc tay hoặc nếu tôi nên nghiên cứu và tích hợp WF4 (Windows Workflow 4.0, một phần của .NET 4.0) để WF trở thành theo nghĩa đen là bộ điều khiển của toàn bộ ứng dụng, nghĩa là C thực tế trong "MVC" (không phải ASP.NET MVC mà đúng hơn là mẫu). Vì vậy, hoạt động của luồng công việc trong WF4 có phải là bộ điều khiển chính cho ứng dụng cộng tác dựa trên web có thể mở rộng/phát triển cao? Hay tôi hỏi hoàn toàn câu hỏi sai?

Đây là một câu hỏi mơ hồ, tôi chắc chắn, vì vậy câu trả lời trừu tượng được chào đón như những người cụ thể.

Tôi biết rằng WF4 là một bản làm lại đáng kể và thiết kế lại WF3, phần lớn những gì làm cho WF3 trở thành một sự lựa chọn công nghệ kém đã được dọn sạch trong WF4. Ví dụ, như xa như tôi có thể nói (mặc dù tôi đã không nhìn rất khó khăn, và hầu như không có bảo hiểm về điều này), WF4 hoạt động được nhiều hoặc ít testable với [TestMethod] và mocking (ai đó có thể biết xin vui lòng xác nhận? .. testability của WF là một mối quan tâm lớn đối với chúng tôi). Tôi có rất ít quan tâm đến việc lập sơ đồ hoặc tải trễ qua XML với WF, tôi thích viết các khai báo dòng công việc C# cụ thể hơn, nhưng nếu một luồng công việc có thể được viết gọn gàng bằng ngôn ngữ biên dịch và có thể kiểm tra được, tôi bị cám dỗ trả tiền chú ý đến nó. Vì vậy, nếu những cải tiến này có ở đó, những thứ khác như hiệu suất được cải thiện đã thu hút sự chú ý của tôi về công nghệ một lần nữa, trong khi tôi đã pooh-poohed WF3. Ngoài ra, theo Microsoft, WF4 là những gì Microsoft muốn tiêu chuẩn hóa cho tất cả các sản phẩm hướng dòng công việc trong tương lai, sau khi các bài học rút ra từ việc có các công nghệ quy trình làm việc khác nhau trong MS CRM, MS SharePoint, v.v. tò mò về cá cược trên một tính năng một kích thước phù hợp với tất cả, nhưng chỉ khi triển khai có thể ngắn gọn, kiểm tra loại tại thời gian biên dịch, có thể kiểm tra và duy trì được.

CHỈNH SỬA: Chỉ câu trả lời từ những người biết WF4 (không phải WF3) sẽ được xem xét cho "câu trả lời".

Answer 1

Không, tôi sẽ không đặt nó ở giữa mọi thứ.

Tôi hiện đang tham gia vào một dự án sử dụng rộng rãi quy trình làm việc 3. Không phải luồng công việc 4 và tôi hiểu rằng có rất nhiều cải tiến trong WF4, nhưng ... quy trình làm việc là luồng công việc.

Tôi thường nói rằng nó thú vị, thú vị và có lợi khi học các công nghệ mới. Bạn có thể đạt được những quan điểm và hiểu biết mới. Nhưng theo ý kiến ​​của tôi, dự án tôi đang làm là sử dụng quá nhiều công việc. Nó đang được sử dụng cho sự kiên trì đối tượng, các sự kiện dựa trên bộ đếm thời gian và theo dõi trạng thái quá trình. Nó có thể làm tất cả những điều này, nhưng tôi không tin rằng nó thêm bất cứ thứ gì vào hệ thống.

Tôi chắc chắn hoài nghi dựa trên trải nghiệm luồng công việc 3 của mình, nhưng cho đến nay tôi đã tìm thấy quy trình làm việc khó khăn hơn để gỡ lỗi, khó tích hợp hơn và chịu trách nhiệm giới thiệu nhiều tình huống chủng tộc. hoạt động độc lập trong các phần khác nhau của quy trình của tôi.

Nếu bạn không cần sử dụng quy trình làm việc không đạt được bất kỳ lợi ích cụ thể, hữu hình nào khi sử dụng, thì tại sao lại thêm độ phức tạp và rủi ro cho hệ thống của bạn? Chỉ vì bạn 'có thể' hoặc 'có thể' sử dụng quy trình làm việc là không đủ lý do. Nếu bạn muốn đào sâu nó vào thì hãy xây dựng một món đồ chơi bằng cách sử dụng nó, hoặc có thể ném một hoặc hai luồng công việc vào hệ thống của bạn trong các vai trò không quan trọng.

Cân nhắc xem bạn có đang sử dụng bất kỳ tính năng cụ thể và độc đáo nào của quy trình làm việc hay không. Ví dụ. có thể kiểm tra không phải là tính năng của quy trình làm việc; nó sẽ không dễ dàng hơn để thử nghiệm một luồng công việc hơn là một khối mã.

Có rất ít điều bạn có thể thực hiện trong quy trình làm việc mà bạn không thể làm trong mã đơn giản (tôi nói 'rất ít' vì tôi chắc chắn có một số, nhưng tôi không biết). Bạn cần phải cân nhắc những lợi ích và tổn thất của bạn, và xây dựng một bằng chứng về khái niệm.