Tôi thiếu gì về WCF?

Question

Tôi đã phát triển trong công nghệ MS lâu hơn tôi quan tâm để nhớ ở giai đoạn này. Khi .NET đến hiện trường, tôi nghĩ rằng họ đánh vào đầu và với mỗi lần lặp lại và phiên bản tôi nghĩ công nghệ của họ ngày càng mạnh mẽ hơn và mong chờ mỗi lần phát hành.

Tuy nhiên, khi phải làm việc với WCF trong năm qua, tôi phải nói rằng tôi thấy công nghệ này rất khó để làm việc và hiểu. Ban đầu nó khá hấp dẫn nhưng khi bạn bắt đầu thâm nhập vào nó, cấu hình là một cơn ác mộng, phải ghi đè các hành vi đối với kích thước tin nhắn, số lượng đối tượng chứa trong tin nhắn, sự phức tạp của mô hình bảo mật, xử lý proxy khi bị lỗi và cuối cùng di chuyển trở lại để xác định các giao diện trong mã thay vì trong XML.

Nó không hoạt động ra khỏi hộp và tôi nghĩ là cần. Chúng tôi đã tìm thấy tất cả các vấn đề trên trong khi thử nghiệm bản thân hoặc người khác khi sản phẩm của chúng tôi xuất hiện trên trang web.

Tôi hiểu lý do cơ bản đằng sau tất cả, nhưng chắc chắn họ có thể đã đưa ra cơ chế triển khai đơn giản hơn.

Tôi cho rằng những gì tôi đang hỏi là,

• Tôi nhìn vào WCF một cách sai lầm?
• Điểm mạnh nào có trên các lựa chọn thay thế ?
• Trong trường hợp nào tôi nên chọn sử dụng WCF?

Folks OK, Xin lỗi về sự chậm trễ trong việc đáp ứng, làm việc không có một thói quen khó chịu của nhận được trong cách đôi khi :)

Một số làm rõ điểm sơn chính của tôi với WCF Tôi cho rằng rơi xuống sau khu vực Trong khi nó hoạt động ra khỏi hộp, bên trái của bạn với một số bất ngờ lớn dưới mui xe. Như đã chỉ ra ở trên điều cơ bản bị hạn chế cho đến khi họ được ghi đè

1. Kích thước của chuỗi hơn có thể được thông qua không thể so với 8K
2. Số đối tượng có thể được thông qua trong một tin nhắn duy nhất là hạn chế
3. Proxy không tự động khôi phục từ thất bại
4. Số lượng cấu hình trong khi đó là điều tốt, nhưng hãy hiểu tất cả và sử dụng những gì và trong trường hợp nào có thể khó hiểu. Khi nói về cấu hình, chúng ta phải ẩn rất nhiều dữ liệu trong cơ sở dữ liệu phía sau vì người bảo mật và mạng đang cố gắng thay đổi mọi thứ trong tập tin cấu hình mà không cần hiểu nó.
5. Giữ cấu hình của các giao diện trong mã thay vì di chuyển đến các giao diện được xác định rõ ràng trong XML, có thể được xuất bản và sử dụng bởi hầu hết mọi thứ. Tôi biết chúng tôi có thể xuất XML từ hội đồng, nhưng nó đầy rác và một số máy tạo mã nào đó bị nghẹt thở trên nó.

Tôi biết thế giới đang di chuyển, tôi đã di chuyển nhiều lần trong lần cuối cùng (ahem 22 năm tôi đã phát triển) và đang tích cực sử dụng WCF, vì vậy đừng hiểu lầm tôi hiểu nó là gì và nó ở đâu.

Tôi chỉ nghĩ rằng nên có các tùy chọn cấu hình/triển khai đơn giản hơn, thiết lập dễ dàng hơn và quản lý tốt hơn cho cấu hình (nhà cung cấp cấu hình SQL có thể, thay vì chỉ tệp web.config/app.config).

Answer 1

Tôi sẽ giải quyết các vấn đề còn lại của bạn sau khi làm rõ. Trong thời gian chờ đợi, tôi có thể giải quyết câu hỏi của bạn khi bạn nên chọn sử dụng WCF: luôn luôn.

WCF là sự thay thế cho các công nghệ ASMX cũ, bao gồm cả WSE. Nó cũng là sự thay thế cho .NET Remoting. Đây là công nghệ duy nhất mà các tính năng liên lạc cao cấp trong .NET sẽ dựa trên tương lai thuận lợi.

Ví dụ: hãy xem xét Windows Azure. Nó không phải là không thể tránh khỏi mà khái niệm mới về "điện toán đám mây" sẽ có các khía cạnh truyền thông của nó được bảo vệ bởi WCF. Tuy nhiên, WCF đủ linh hoạt để được mở rộng để trang trải những trường hợp đó, với rất ít thay đổi về mã.

Nếu bạn đang gặp rắc rối với WCF, sau đó bạn sẽ làm tốt để đảm bảo Microsoft biết về nó. WCF là hiện tại và tương lai của dịch vụ web và phát triển dịch vụ theo định hướng khác trong .NET, vì vậy họ đã có một động lực rất mạnh mẽ để lắng nghe bạn và giải quyết các điểm đau của bạn. Hoặc liên hệ trực tiếp với họ thông qua Connect hoặc đặt câu hỏi tại đây trên SO (thẻ với WCF, vui lòng) và rất nhiều người sẽ giúp bạn.

Answer 2

Tôi sử dụng WCF mọi lúc và tôi chia sẻ nỗi đau của bạn. Có vẻ như nó đã được thiết kế quá mức, nhưng chúng tôi sẽ bị mắc kẹt trong một thời gian dài, vì vậy tôi đang cố gắng tìm hiểu nó.

Một điều tôi chắc chắn về, XML hút. Tôi đã không có gì, nhưng vấn đề bằng cách sử dụng XML để kiểm soát nó và có kể từ khi chuyển sang xử lý tất cả mọi thứ thông qua mã.

Answer 3

Nhìn vào cách bạn đề cập đến XML và SQL, bạn đang sử dụng WCF để xây dựng ứng dụng web hoặc dịch vụ web thực (dịch vụ trên Web chứ không chỉ trao đổi SOAP).

Nó giúp suy nghĩ về WCF như là một thay thế cho .NET Remoting (hoặc DCOM, CORBA, vv), cũng sẽ xảy ra để hỗ trợ các dịch vụ web như một trong các phương tiện vận tải. Các giao diện được khai báo trong các assembly, hành vi của proxy, các tùy chọn cấu hình và các khía cạnh khác của khung nhìn không tự nhiên và phức tạp từ quan điểm của các ứng dụng web - thực sự làm việc ra khỏi hộp cho các hệ thống kiểu DCOM của các đối tượng phân tán.

Để trả lời câu hỏi: không, bạn không bỏ sót bất cứ điều gì và sử dụng WCF cho các ứng dụng web phức tạp, vì WCF không phải là khuôn khổ để xây dựng các ứng dụng web. Có lẽ khung như vậy có thể được xây dựng trên đầu trang của nó, nhưng tôi ghét phải nhìn thấy WCF chính nó thay đổi để di chuyển vào lĩnh vực web.

Answer 4

Để giải quyết vấn đề về cơn ác mộng bảo trì của cấu hình ứng dụng, một số tiêu chuẩn như UDDI hoặc WS-Discovery tồn tại, WS-Discovery sẽ được WCF hỗ trợ trong .NET 4.0.

Giữ cấu hình của giao diện trong mã chứ không phải di chuyển để xác định rõ ràng các giao diện trong XML, có thể được công bố và tiêu thụ bởi hầu hết mọi thứ. Tôi biết chúng tôi có thể xuất XML từ assembley, nhưng nó đầy rác và một số máy phát mã số bị nghẹt thở trên đó.

Bạn có thể rõ ràng hơn không? Tôi nghĩ bạn đang nói về hành vi dịch vụ được cấu hình trong mã. Bạn có thể dễ dàng mã các phần mở rộng hành vi để cấu hình những gì bạn đang nói về trong tập tin cấu hình thay vì mã BUT Tôi nghĩ rằng nếu microsoft không làm điều đó có một lý do chính đáng. Ví dụ một dịch vụ với hành vi này:

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall, ConcurrencyMode=ConcurrencyMode.Single)] 

Việc thực hiện đều biết rằng các trường hợp không được chia sẻ giữa nhiều chủ đề để nó phát triển khác với:

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple)] 

Trong trường hợp này việc thực hiện dịch vụ nên chăm sóc về vấn đề đồng thời. Việc triển khai được kết hợp với thuộc tính ServiceBehavior, vì vậy việc di chuyển hành vi này trong một tệp XML không phải là một ý tưởng hay.

Điều gì sẽ xảy ra nếu bạn có thể thay đổi dịch vụ InstanceContextMode.PerCall thành dịch vụ InstanceContextMode.Single bên trong tệp cấu hình? Bạn phá vỡ các ứng dụng!

Answer 5

Các mối quan tâm bạn được liệt kê là:

---

1. Kích thước của chuỗi hơn có thể được thông qua không thể so với 8K
2. Số đối tượng có thể được thông qua trong một tin nhắn duy nhất là hạn chế
3. Proxy không tự động khôi phục từ thất bại
4. Số lượng cấu hình trong khi đó là điều tốt, nhưng hãy hiểu tất cả và sử dụng những gì và trong trường hợp nào có thể d ifficult để hiểu. Khi nói về cấu hình, chúng ta phải ẩn rất nhiều dữ liệu trong cơ sở dữ liệu phía sau vì người bảo mật và mạng đang cố gắng thay đổi mọi thứ trong tập tin cấu hình mà không cần hiểu nó.
5. Giữ cấu hình của các giao diện trong mã thay vì chuyển sang giao diện được xác định rõ ràng trong XML, có thể được xuất bản và sử dụng bởi hầu hết mọi thứ. Tôi biết chúng tôi có thể xuất XML từ hội đồng, nhưng nó đầy rác và một số máy tạo mã nào đó bị nghẹt thở.

---

đây là quan điểm của tôi:

(1) giải quyết một mối quan tâm hợp lệ mà khách hàng đã có với ASMX. Nó quá rộng, không có cách nào để dễ dàng kiểm soát nó. Giới hạn 8k dễ dàng được dỡ bỏ nếu bạn biết nơi cần tìm. Tôi đoán bạn có thể đếm đó như một sự ngạc nhiên, nhưng đó là một điều một lần nữa. Một khi bạn biết về nó, bạn có thể nâng nó và được thực hiện với nó mãi mãi, nếu bạn chọn.

(2) cũng có thể định cấu hình được.

(3) được biết, nhưng có những cách sắp xếp sẵn để khắc phục sự cố này. Ví dụ, mã StockTrader thể hiện một mẫu đã được chứng minh. Bạn có thể sử dụng lại mã trong ứng dụng của riêng mình. Không chắc chắn nếu điều này là cố định trong WCF cho .NET 4.0. Tôi biết đó là một yêu cầu mở.

(4) Cấu hình là một con thú. Đây là một mối quan tâm cho rất nhiều người. Vấn đề ở đây là WCF rất linh hoạt và cấu hình tất cả tính linh hoạt đó được hiển thị thông qua các tệp xml. Nó có thể được áp đảo. Một cách tiếp cận dường như hoạt động là dùng nó trong những vết cắn nhỏ, khi bạn cần.

(5) Tôi không hiểu.

Answer 6

Lợi thế lớn nhất khi sử dụng WCF từ quan điểm của người lập trình: phân tách định nghĩa dịch vụ được tiếp xúc (hoạt động, hợp đồng, v.v.) từ chi tiết cụ thể của giao thức, không giống như ASMX nơi bạn hiển thị lớp học dưới dạng dịch vụ web trực tiếp mã sử dụng các thuộc tính. Sử dụng ví dụ thực sự của tôi: chúng tôi có thể dễ dàng chuyển đổi giao thức truyền tải giữa các dịch vụ web và các đường ống có tên, bất kỳ điều gì phù hợp hơn với nhu cầu triển khai và hiệu suất, mà không thay đổi dòng mã.

Answer 7

WCF dành cho các phương pháp SOA. Công việc chuyên nghiệp sử dụng nó là một cơn ác mộng. Tôi đã cung cấp một giải pháp SOA sử dụng WCF làm công cụ và địa ngục, hàng trăm cấu hình và các mẹo ẩn! Giải pháp phân phối trước đây của tôi bằng cách sử dụng Dịch vụ web và Từ xa cũ đã ổn định hơn. Tôi đã dành nhiều ngày để giải quyết lỗi "Kết nối cơ bản đã bị đóng: Đã xảy ra lỗi không mong muốn", điều này không có ý nghĩa gì đối với một phương thức trong số 4 trong cùng một hợp đồng. Tôi rất thất vọng. Nó đã đưa tôi trở lại thông qua thời gian mà. Net lần đầu tiên được giới thiệu với rất nhiều lời hứa và khi chúng tôi có bàn tay trên, địa ngục, vấn đề đăng nhập đã đưa ra!

Answer 8

Tôi rất thích ASP.NET MVC và API Web qua WCF. Nếu tôi phải tóm tắt WCF cho một nhà phát triển, người vừa mới được giới thiệu với nó, tôi sẽ nói, "WCF là một nỗ lực có ý nghĩa để thay thế cho phát triển RPC kiểu Java EE quá mức." Thật không may, nhiều quyết định được yêu cầu bạn trở thành chuyên gia trong việc định cấu hình các mục thấp, không quan trọng (kích thước thư, thời gian chờ, yếu tố giao thức không quan tâm, v.v.) trong khi trừu tượng các phần cực kỳ quan trọng (thiết kế URL, serialization tham số, serialization đáp ứng, v.v.). Sự khác biệt về năng suất và tình tiết tăng nặng giữa các nhóm mà tôi biết khi sử dụng WCF so với API Web là ban đêm và ban ngày.

Để trở nên sạch sẽ một chút: Tôi đã luôn luôn ghét khái niệm cốt lõi của .NET Remoting. Tôi cảm thấy rằng các nhà phát triển cần một sự hiểu biết thấu đáo về cấu trúc tài nguyên của ứng dụng của họ và cách các tài nguyên này được tuần tự hóa. Hơn nữa, việc sử dụng động từ "POST" để thu thập dữ liệu đơn giản là đáng lo ngại trong một ứng dụng đọc nặng cần phải mở rộng.