Làm cách nào để quản lý cuộc tranh luận kỹ thuật về WCF so với API Web?


49

Hiện tôi đang quản lý một nhóm gồm 15 nhà phát triển và chúng tôi đang gặp khó khăn trong việc lựa chọn công nghệ, trong đó nhóm được chia thành hai nhóm hoàn toàn trái ngược nhau, tranh luận về việc sử dụng WCF so với API Web.

Nhóm A hỗ trợ sử dụng API Web, đưa ra những lý do sau:

  1. API Web chỉ là cách viết dịch vụ hiện đại ( Wikipedia )
  2. WCF là một chi phí chung cho HTTP. Đó là một giải pháp cho TCP và Net Faucet và các giao thức khác
  3. Các mô hình WCF không phải là POCO, vì [DataContract] & [DataMember] và các thuộc tính đó
  4. SOAP không dễ đọc và tiện dụng như JSON
  5. SOAP là một chi phí chung cho mạng so với JSON (truyền qua HTTP)
  6. Không quá tải phương thức

Đội B hỗ trợ việc sử dụng WCF, nói:

  1. WCF hỗ trợ nhiều giao thức (thông qua cấu hình)
  2. WCF hỗ trợ giao dịch phân tán
  3. Nhiều ví dụ hay và câu chuyện thành công tồn tại cho WCF (trong khi API Web vẫn còn trẻ)
  4. Song công là tuyệt vời cho giao tiếp hai chiều

Cuộc tranh luận này đang tiếp diễn và tôi không biết phải làm gì bây giờ. Cá nhân, tôi nghĩ rằng chúng ta chỉ nên sử dụng một công cụ cho đúng nơi sử dụng . Nói cách khác, chúng tôi nên sử dụng API Web tốt hơn, nếu chúng tôi muốn đưa ra một dịch vụ qua HTTP, nhưng sử dụng WCF khi nói đến TCP và Duplex.

Bằng cách tìm kiếm trên Internet, chúng ta không thể có được kết quả vững chắc. Nhiều bài viết tồn tại để hỗ trợ WCF, nhưng ngược lại chúng tôi cũng thấy mọi người phàn nàn về nó. Tôi biết rằng bản chất của câu hỏi này nghe có vẻ tranh cãi, nhưng chúng ta cần một số gợi ý tốt để quyết định. Chúng ta bị mắc kẹt tại một thời điểm mà việc lựa chọn một công nghệ tình cờ có thể khiến chúng ta hối tiếc về sau. Chúng tôi muốn chọn với đôi mắt mở.

Việc sử dụng của chúng tôi chủ yếu dành cho web và chúng tôi sẽ đưa ra các dịch vụ của mình qua HTTP. Trong một số trường hợp (giả sử 5 đến 10 phần trăm), chúng tôi có thể cần các giao dịch phân tán.

Tôi nên làm gì bây giờ? Làm cách nào để quản lý cuộc tranh luận này theo cách xây dựng?


11
Đừng quên, API Web không giúp người tiêu dùng dễ dàng tạo ứng dụng khách dịch vụ như WAPL SOAP. Nếu bạn chỉ có các máy khách .NET thì đó không phải là vấn đề lớn vì họ có thể chia sẻ các đối tượng hợp đồng mà bạn triển khai, nhưng các khách hàng ngôn ngữ khác sẽ cần phải tạo thủ công các đối tượng khách của họ nếu bạn không sử dụng SOAP.
Jimmy Hoffa

10
cũng nên nhớ rằng WCF cũng có thể thực hiện json khá tốt trong hầu hết các trường hợp
Bill

3
"3. Các mô hình WCF không phải là POCO" đơn giản là không chính xác. Bạn không phải sử dụng bất kỳ thuộc tính nào kể từ .NET 3.5 SP1.
Allon Guralnek

4
Câu hỏi này dường như lạc đề vì nó liên quan đến việc quản lý một cuộc tranh luận giữa các đồng nghiệp, chứ không phải về phát triển phần mềm.
GrandmasterB

3
Wikipedia định nghĩa "cách viết dịch vụ hiện đại"? Không chắc làm thế nào là hữu ích.
Frank Hileman

Câu trả lời:


38

Khi cả hai bên có những tranh luận tốt và ý kiến ​​về vấn đề này quá mạnh để đi đến thống nhất, bạn là người quản lý cần đưa ra quyết định và kết thúc cuộc tranh luận. Nếu không, nó sẽ chỉ xoay theo vòng tròn và củng cố vị trí của tất cả những người tham gia hơn nữa. Bạn càng chờ đợi lâu, bên "thua" sẽ càng khó chấp nhận thất bại và làm việc hiệu quả với kết quả.

Viết ra tất cả các đối số, đánh giá tầm quan trọng của chúng đối với dự án và sau đó đưa ra quyết định của bạn. Khi bạn không thể, lật một đồng xu. Dự án của bạn có thể được hoàn thành thành công với một trong hai công nghệ và lãng phí thời gian quý báu với các cuộc tranh luận không cần thiết sẽ chỉ tốn tiền không cần thiết.


3
Gửi @Philipp, cảm ơn vì đã gợi ý lật xu . Nhưng như tôi đã nói, tôi không muốn hối hận về quyết định cơ hội này . Trong khi tôi tin rằng vấn đề nhanh nhẹn, tôi cũng tin rằng quyết định tốt cũng quan trọng.
Saeed Neamati

5
@SaeedNeamati: Nếu, sau khi thu thập và cân nhắc tất cả thông tin, không có công nghệ nào có lợi thế rõ ràng, thì lật một đồng xu là cách quyết định trung thực nhất. Bất kể kết quả của việc tung, đó là một quyết định tốt, bởi vì bạn đã cân nhắc tất cả thông tin.
Bart van Ingen Schenau

9
@SaeedNeamati: Tôi hoàn toàn đồng ý với "lật một đồng xu". Ngay bây giờ bạn đang trong tình trạng tê liệt phân tích rõ ràng (các từ chính xác của bạn nằm trên trang wiki đó), IMO nguy hiểm hơn là chọn một quyết định có thể không phải là "tốt nhất". Nếu bạn có một quyết định khó khăn như vậy, điều đó có nghĩa là ngay cả quyết định khác, ít tối ưu hơn cũng không tệ. Và miễn là bạn kiến ​​trúc sư phần mềm của mình theo cách mô đun, bạn sẽ có thể để lại sự trừu tượng đủ để đưa một công nghệ ra và đưa công nghệ kia vào nếu cần, điều này rất khó xảy ra trong cả hai trường hợp.
DXM

2
@SaeedNeamati Về mặt công nghệ, không có gì gọi là "hối tiếc" về quyết định này. Bạn sẽ luôn mắc sai lầm. Điều quan trọng hơn là có thể phát hiện sai lầm càng sớm càng tốt, thừa nhận chúng một cách cởi mở và thay đổi quyết định để tốt hơn.
ngủ Smith

4
Các lựa chọn khác: đấu tay đôi; trận đấu vật; người nào hét to nhất sẽ thắng. Chắc chắn những điều này là tốt hơn so với lật một đồng tiền? :)
Frank Hileman

13

Giả sử cả hai bên đều đúng 100% trong tất cả các lập luận của họ, vấn đề nào quan trọng?

Các mô hình WCF không phải là POCO, vì [DataContract] & [DataMember] và các thuộc tính đó

Bạn có quan tâm không? Bạn có kế hoạch làm một cái gì đó yêu cầu POCO?

WCF hỗ trợ giao dịch phân tán

Một lần nữa, đây là thứ bạn sẽ sử dụng và cần xây dựng nếu bạn không có nó bởi vì bạn đã đi theo con đường khác?

Về cơ bản đến trung tâm của một trong những:

  • Cung cấp mọi thứ bạn cần (Nếu không cung cấp mọi thứ bạn cần khiến bạn phải làm ít việc nhất).
  • Cung cấp số lượng rác ít nhất bạn sẽ không sử dụng nhưng dù sao cũng phải đưa ra.

Bất kỳ đối số nào được đưa ra không nằm trong lộ trình của những gì bạn cần thực hiện là không liên quan và không nên ảnh hưởng đến quyết định của bạn, với một số phòng ngọ nguậy để xem xét mở rộng trong tương lai.


1
Các mô hình Dịch vụ Dữ liệu WCF là POCO, chỉ yêu cầu là một trường ID [name] iirc.
Maslow

11

Đặt hai xu của tôi vào.

Là người quản lý, bạn nên yêu cầu đồng đội ghi nhớ nguyên tắc Yagni . Điều này sẽ giúp giảm danh sách các lý do được đưa ra bởi cả hai Đội.

Việc sử dụng của chúng tôi chủ yếu dành cho web và chúng tôi sẽ đưa ra các dịch vụ của mình qua HTTP. Trong một số trường hợp (giả sử 5 đến 10 phần trăm), chúng tôi có thể cần các giao dịch phân tán.

Thay vì lao vào giao dịch phân tán, bạn nên xem xét làm việc với bồi thường thay thế.

Điều cuối cùng cần tính đến là đường cong học tập. Tùy thuộc vào thời hạn của dự án, với tư cách là người quản lý, bạn sẽ có thể quyết định liệu có ổn không khi bắt đầu học một công nghệ mới hay không.

Nếu bạn có nhiều thời gian để lãng phí, thì hãy đến một ngày nào đó trong Ngày đổi mới , nơi Đội A và B sẽ có một ngày để đưa ra bằng chứng về các khái niệm dựa trên cùng các yêu cầu.

Nhân tiện, với anh chàng nói rằng " các mô hình WCF không phải là POCO, vì [DataContract] & [DataMember] và các thuộc tính đó ", nói với anh ta rằng POCO có nghĩa là các thực thể miền và đó không phải là cách thực hành tốt nhất để phơi bày đối tượng tên miền của bạn cho bất kỳ loại khách hàng nào, đây là mục đích của DTO.


+1 vì không để lộ các đối tượng miền trong hợp đồng bên ngoài +1 cho các giao dịch phân tán, đó là một điều rất xấu ..
user1496062

5

Tôi nên làm gì bây giờ? Làm cách nào để quản lý cuộc tranh luận này theo cách xây dựng?

Đầu tiên, hãy chủ quan tránh xa. Trong các đối số của nhóm WebAPI của bạn, tôi thấy "API Web chỉ là cách hiện đại" *, "các mô hình WCF không phải là POCO, vì các thuộc tính đó""SOAP không dễ đọc và tiện dụng như JSON" , nếu không nói sai và sẽ không giúp đưa ra quyết định.

Vì vậy, phải làm gì: quyết định những gì bạn muốn làm với (các) dịch vụ của bạn , sau đó chọn một kỹ thuật phù hợp với mục tiêu đó và khả năng duy trì cũng như khả năng mở rộng của nó với ít đau nhất. Bạn có thể làm điều này bằng cách đơn giản nghiên cứu xem bất kỳ khía cạnh cụ thể nào được hỗ trợ bởi khung để sử dụng.

Tài liệu đọc thú vị:

*: lưu ý bạn tham khảo Wikipedia về điều này, trong đó trích dẫn là: "Các ứng dụng web Web 2.0 đã rời khỏi kiến ​​trúc hướng dịch vụ (SOA) với các dịch vụ web dựa trên SOAP hướng tới các bộ sưu tập tài nguyên web RESTful gắn kết hơn" . Đó là một ví dụ về việc sử dụng khi dịch vụ của bạn được sử dụng từ một trang web. Điều này cũng có thể dễ dàng được thực hiện với WCF, bằng cách sử dụng WebHttpBinding. Nó không nói "Sử dụng WebAPI cho việc này" .

Nếu câu hỏi này vượt ra ngoài "cách quản lý cuộc thảo luận" : Tôi sẽ sử dụng WCF nếu các dịch vụ không được sử dụng bởi các khách hàng không phải là khách hàng, vì siêu dữ liệu của nó cho phép tạo ra ứng dụng khách được gõ mạnh dễ dàng một cách đáng kinh ngạc.


1
Không chỉ thế. " XYZ chỉ là cách hiện đại " là một lý lẽ NULL, thường được đọc là " Tôi không có tranh luận thực sự, nhưng đó là sở thích cá nhân của tôi về mùa giải. "
JensG

4

Quản lý nhóm sang một bên, bạn không chọn cái này hơn cái kia. Bạn cần xem xét mục đích của từng dịch vụ web và sử dụng công nghệ thích hợp cho phần cụ thể của ứng dụng. Nó giống như cấm các thủ tục cửa hàng khi nhóm đang sử dụng khung thực thể.

Việc sử dụng của chúng tôi chủ yếu dành cho web và chúng tôi sẽ đưa ra các dịch vụ của mình qua HTTP. Trong một số trường hợp (giả sử 5 đến 10 phần trăm), chúng tôi có thể cần các giao dịch phân tán.

Sau đó, bạn viết các dịch vụ web 5 ~ 10% đó trong WCF. Nếu dịch vụ được tham chiếu nội bộ trong các dự án khác, sẽ không có tranh luận. Lợi thế của khả năng nhập hợp đồng WCF để tạo proxy máy khách là KHÔNG mở để thảo luận. Nó đưa toàn bộ sự tích hợp, hiệu quả và loại an toàn lên một cấp độ hoàn toàn mới.

Bạn viết những gì sẽ được sử dụng cho các yêu cầu api công khai (có thể) / Ajax trong api web Asp.net.

Nếu đó chỉ là cuộc gọi ajax cụ thể của trang, bạn chỉ có thể sử dụng Asp.Net MVC.

Đừng chọn, hãy nắm lấy tất cả. Api WCF và Asp.net phục vụ các mục đích khác nhau. Không ai nói rằng bạn không thể có táo và cam trong món salad trái cây của bạn. Cố gắng chọn cái này qua cái khác và đẩy nó xuống từng kịch bản chỉ là sự lười biếng.


4

Nhóm của chúng tôi đã có một cuộc thảo luận tương tự một vài tháng trước. Yếu tố quyết định đối với chúng tôi là cách chúng tôi tạo ra và triển khai từng công nghệ. Vì chúng tôi đã xây dựng một ứng dụng MVC và đang sử dụng Knockout.js để liên kết dữ liệu, chúng tôi đã sử dụng MVVM một cách hiệu quả với các bộ điều khiển chỉ là một API cho dữ liệu.

Điều này cho phép chúng tôi phân loại việc sử dụng các công nghệ với dự án này như sau:

  • API Web sẽ được sử dụng làm API của chúng tôi cho các cuộc gọi loại trực tiếp và Ajax, biến chúng thành các lệnh của chúng tôi cho mẫu MVVM. Logic kinh doanh của chúng tôi cho ứng dụng web được gói gọn phía sau lớp này thông qua một số lớp và kho lưu trữ và nhà máy.
  • WCF sau đó được sử dụng cho kho lưu trữ dữ liệu của chúng tôi, hiển thị dữ liệu từ cơ sở dữ liệu của chúng tôi không chỉ cho trang web này, mà còn cho bất kỳ trang web hoặc dịch vụ nào khác sử dụng dữ liệu bị lộ.

Mặc dù điều này có thể không phải là một phản ứng phổ biến hoặc siêu kỹ thuật, việc xác định những gì bạn cần trước tiên và làm thế nào hoặc liệu công nghệ sẽ giúp gì là điều giúp nhóm của tôi quyết định sử dụng công nghệ nào ở đâu.


Làm thế nào để lớp WCF của bạn xử lý Auth?
Maslow

3

Nói cách khác, chúng tôi nên sử dụng API Web tốt hơn, nếu chúng tôi muốn đưa ra một dịch vụ qua HTTP, nhưng sử dụng WCF khi nói đến TCP và Duplex.

Đó sẽ là cách tiếp cận hợp lý nhất. Điều khá phổ biến là có cả dịch vụ WCF và WebApi trong cùng một ứng dụng web, nơi cả hai đều phục vụ các mục đích khác nhau.

Chỉ cần sửa một vài đối số:

Các mô hình WCF không phải là POCO, vì [DataContract] & [DataMember] và các thuộc tính đó

Trong nhiều trường hợp, các mô hình WCF hoạt động mà không có các thuộc tính datacontract / datamember.

SOAP không dễ đọc và tiện dụng như JSON

Điều đó không đúng, nhưng các dịch vụ web WCF thường mang XML đơn giản hơn là SOAP cồng kềnh. Điều này chắc chắn có thể đọc được.

Một lập luận cho WCF: nếu có sẵn WSDL, có hàng tấn công cụ trong hầu hết tất cả các công nghệ có thể tạo proxy từ siêu dữ liệu. Mặt khác, Lược đồ JSON chưa được hỗ trợ rộng rãi.


2

Tại sao không đi bộ với Dịch vụ Dữ liệu WCF? truy vấn kiểu OData / webapi đẹp và khả năng sử dụng với sức mạnh của WCF và khả năng trả về JSONtốt. Ngoài ra Wcf không tệ nếu bạn có mã lưu trữ wcf tự động đẹp như sau:

https://github.com/ImaginaryDevelopment/MvcOdata

Tôi muốn nói rằng họ hoàn toàn không tách biệt nhau, ngoại trừ khi chúng tôi sử dụng WebApiở mặt trước và WCF data servicesở tầng giữa, họ WebApiđã sử dụng những thứ đơn giản như chuỗi chứa hoặc chuỗi toán tử khớp với chuỗi.


1

Một kiến ​​trúc sư giỏi sẽ trì hoãn các quyết định công nghệ cho đến khi chúng thực sự cần thiết.

Nói cách khác, đừng đưa ra quyết định cho đến khi khách hàng cần thực sự kết nối. Bạn có thể xây dựng một lớp dịch vụ được kiểm tra đầy đủ mà không thực sự đặt một cơ chế vận chuyển / giao tiếp trên nó. 95% + công việc có thể được thực hiện "bên dưới" bộ điều hợp, bên ngoài khung.

Hãy đến lúc để trưng bày các dịch vụ đó cho các khách hàng ở xa, bạn có thể chọn khung thời trang nhất ra khỏi kệ và viết các hàm bao mỏng trên một lớp dịch vụ đa năng.

Chết tiệt, nếu lớp dịch vụ "thực" của bạn được thực hiện tốt, bạn thậm chí có thể thử một vài hàm bao với chi phí tối thiểu.

Dù sao đó cũng là câu trả lời giáo điều. Trong thực tế , bạn có thể muốn chọn công cụ đơn giản nhất ra khỏi kệ để tạo điều kiện cho các thử nghiệm tích hợp sớm và thường xuyên - nhưng, vẫn hạn chế sự phụ thuộc của bạn vào nó và coi nó là một lớp giao tiếp đơn giản so với các dịch vụ thực .


Nếu bạn thực hiện phương pháp này, có thể bạn sẽ thấy rằng bạn chọn công cụ đơn giản nhất để sử dụng ban đầu và sẽ không có ai làm phiền , bởi vì nhóm biết rằng họ có thể thực hiện một công cụ hoặc khung thời trang tinh vi hơn hoặc hợp thời trang hơn, nếu cần , với nỗ lực tối thiểu.


Phải thừa nhận rằng, câu trả lời này rất muộn cho trò chơi - nhưng, tôi thực sự ngạc nhiên khi thấy không có câu trả lời phổ biến nào lấy lại giáo điều "thậm chí không đưa ra quyết định cuối cùng" trả lời ...
svidgen

0

Do đó hiện tại tôi đang phải đối mặt với sự lựa chọn tương tự, tôi đã tự hỏi mình tập hợp các tính năng từ WCF mà nhóm chúng tôi đang sử dụng là gì. Chúng ta có sử dụng các giao thức khác nhau không? Không. Chúng tôi có sử dụng hỗ trợ giao dịch không? Không (mặc dù chúng tôi sử dụng các cơ chế thống nhất cuối cùng tùy chỉnh). Chúng ta có sử dụng song công không? Không.

Tại sao chúng tôi muốn sử dụng API Web? Tích hợp lối vào dễ dàng hơn (loại bỏ lớp dịch vụ bổ sung hiện có), SignalR để đẩy trả lời cho khách hàng, lưu vào bộ đệm cho GET.

Có thể, người ta có thể tìm thấy những lý do khác :) Cũng như, lý do để ở lại với WCF.


2
OP không hỏi về WCF và API Web, OP đang hỏi về cách quản lý cuộc tranh luận nội bộ, kỹ thuật mà nhóm của anh ấy đang gặp phải. Câu trả lời của bạn bỏ lỡ phần rộng hơn của câu hỏi.

0

Nếu tôi ở vị trí của bạn, tôi sẽ bắt đầu bằng cách kiểm tra khả năng của đội bạn. Nếu mọi người trong nhóm của bạn đã biết WCF và chỉ một tỷ lệ nhỏ biết API Web thì quyết định của bạn đã được đưa ra cho bạn.

Bằng mọi cách nếu bạn có thời gian thì hãy đầu tư vào việc học và nâng cao kiến ​​thức, nhưng không phải trả giá cho nhu cầu kinh doanh và năng suất của công ty.


0

Tôi sẽ hỏi mô hình tương tác nào bạn cần hỗ trợ? Giao diện bên ngoài mong muốn của bạn giống với RPC hay REST hơn? Theo kinh nghiệm của tôi, nó thường ở đâu đó giữa nhưng chủ yếu là cái này hay cái khác.

Bạn đang tiêu thụ dịch vụ của riêng bạn cho các dự án khác trong .Net? Đây có lẽ là câu hỏi tiết lộ nhất mà bạn có thể hỏi. WCF có lợi thế là có thể trừu tượng hóa các giao diện của bạn thành một thư viện lớp riêng biệt và có thể xây dựng và tiêm vào máy khách của bạn. Là một phần mở rộng cho điều này, bạn có thể gắn kết dự án dựa trên WCF của mình với cả hai điểm cuối JSON và SOAP / WSDL, tôi đã thực hiện nó. WCF cũng cung cấp đảm bảo tốt hơn đối với các giao diện được xác định của bạn.

Điều đó nói rằng, nếu bạn mong muốn có các máy khách từ các nền tảng XML nói chung, hãy để một mình SOAP có một chi phí có thể đo lường được ngoài những điểm cuối JSON đơn giản có. Nếu bạn đi theo lộ trình API JSON / Web, thì bạn sẽ cần trở nên tốt hơn nhiều trong việc ghi lại cách tương tác với các điểm cuối và API của bạn.

Nói chung, tôi khuyên bạn nên viết một tài liệu API đơn giản cho biết cách bạn sẽ gửi dữ liệu và cách bạn muốn phản hồi cho một cấu trúc đối tượng yêu cầu. Viết trường hợp thử nghiệm của bạn theo cách phổ quát nhất, và ghi lại như vậy. Tôi muốn giới thiệu một tuyên bố curl đơn giản. Sau đó, có một số thành viên của bạn thực hiện điều này bằng cách sử dụng WCF và với API Web. Sau đó xem cái nào thắng.

Cá nhân, mặc dù đã thực hiện một số dự án và triển khai tương đối lớn với WCF, tôi thực sự nghiêng về cách triển khai đơn giản nhất mà theo tôi là WCF thực sự với việc sử dụng kết quả JSON và một số hành vi ghi đè trong Global.asax.cs để xử lý các điều kiện lỗi. Nếu tài liệu của API bao gồm các câu lệnh curl và bạn có thể thực hiện tất cả các chức năng của API bằng các ví dụ curl, việc triển khai ứng dụng khách trở nên dễ dàng hơn nhiều trong bất kỳ ngôn ngữ nào hỗ trợ giao diện web. Đây thực sự là nơi WCF bắt đầu rơi xuống. Có một API được xác định rõ ràng với tài liệu bất khả tri tốt hơn là có các cấu trúc với công cụ tự động khi làm việc với các hệ thống nước ngoài. Nói như một người tiêu dùng của các hệ thống từ các nền tảng khác.

Một điều nữa, đó là triển khai ứng dụng khách của bạn bằng hai ngôn ngữ khác nhau. Làm một ứng dụng khách trong C #, nhưng cũng thực hiện một ứng dụng trong Node.js hoặc Python và xem chúng thực sự phù hợp như thế nào. Bài tập đó một mình sẽ giúp bạn rũ bỏ các kết thúc lỏng lẻo trong API của mình.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.