Khi nào thì không nên sử dụng dịch vụ web?

Question

Sử dụng dịch vụ web thường là một cách tiếp cận kiến ​​trúc tuyệt vời. Và, với sự ra đời của WCF trong. Net, nó trở nên tốt hơn. Tuy nhiên, theo kinh nghiệm của tôi, một số người dường như nghĩ rằng các dịch vụ web phải luôn luôn được sử dụng trong lớp truy cập dữ liệu cho các cuộc gọi đến cơ sở dữ liệu. Tôi không nghĩ rằng các dịch vụ web là giải pháp phổ quát.

Tôi đang nghĩ đến các ứng dụng mạng nội bộ nhỏ hơn với vài chục người dùng. Ứng dụng web và dịch vụ web của nó được triển khai cho một máy chủ web chứ không phải trang web. Sẽ không có ứng dụng web nào khác trong tương lai có thể sử dụng dịch vụ web cụ thể này. Dường như với tôi rằng chi phí gọi dịch vụ web không cần thiết làm tăng gánh nặng trên máy chủ web. Có một hit hiệu suất cho các cuộc gọi giữa các quá trình. Việc duy trì và gỡ lỗi mã cho ứng dụng web và dịch vụ web phức tạp hơn. Vậy là triển khai. Tôi chỉ không thấy những lợi thế của việc sử dụng một dịch vụ web ở đây.

Người ta có thể kiểm tra điều này bằng cách tạo hai phiên bản của ứng dụng web, có và không có dịch vụ web và thực hiện kiểm tra căng thẳng, nhưng tôi chưa thực hiện.

Bạn có ý kiến ​​về việc sử dụng các dịch vụ web cho ứng dụng web quy mô nhỏ không? Bất kỳ dịp nào khác khi dịch vụ web không phải là một lựa chọn kiến ​​trúc tốt?

Answer 1

Dịch vụ web là một lựa chọn hoàn toàn khủng khiếp để truy cập dữ liệu. Đó là một tấn trên không và phức tạp cho lợi ích gần như bằng không.

Nếu ứng dụng của bạn sắp chạy trên một máy, tại sao từ chối khả năng thực hiện cuộc gọi truy cập dữ liệu trong quá trình? Tôi không nói về việc truy cập trực tiếp vào cơ sở dữ liệu từ mã UI của bạn, tôi đang nói về việc trừu tượng kho lưu trữ của bạn đi nhưng vẫn bao gồm các assembly của họ trong trang web đang chạy của bạn.

Có những trường hợp tôi muốn giới thiệu các dịch vụ web (và tôi giả sử bạn có nghĩa là SOAP) nhưng chủ yếu là cho khả năng tương tác.

Mức độ chi tiết của dịch vụ cũng được đề cập ở đây. Một dịch vụ theo nghĩa SOA sẽ đóng gói một hoạt động hoặc một quy trình nghiệp vụ. Các phương thức truy cập dữ liệu chỉ là một phần của quá trình đó.

Nói cách khác:

- someService.SaveOrder(order); // <-- bad 
    // some other code for shipping, charging, emailing, etc 

    - someService.FulfillOrder(order); //<-- better 
    //the service encapsulates the entire process 

dịch vụ Web vì lợi ích của các dịch vụ web là chương trình vô trách nhiệm.

Answer 2

Nếu bạn chỉ đang viết một ứng dụng web nhỏ (dưới 50 người dùng) cho mạng nội bộ của bạn, một dịch vụ web có vẻ quá mức cần thiết. Đặc biệt nếu chức năng chính của nó (cung cấp một điểm truy cập duy nhất cho nhiều dịch vụ) sẽ không được sử dụng.

Answer 3

Đối với ứng dụng web quy mô nhỏ (Bạn phải đặt câu hỏi, "Tuy nhiên, nó vẫn luôn là quy mô nhỏ?") Sử dụng dịch vụ web, lớp kinh doanh riêng biệt, lớp dữ liệu, v.v. .

Trước khi bất cứ ai bắn tôi, tôi đồng ý rằng việc tách logic giữa các lớp cùng với các bài kiểm tra đơn vị, tích hợp liên tục, et al đều rực rỡ. Trong vai trò hiện tại của tôi, tôi sẽ hoàn toàn bị mất và lắc lư trong góc mà không có họ. Tuy nhiên, đối với một ứng dụng web có quy mô nhỏ được sử dụng, ví dụ, theo dõi số liên lạc và địa chỉ cho một công ty 36 nhân viên, phân tích chi phí/lợi ích sẽ gợi ý rằng tất cả các "niceties" được liệt kê ở trên sẽ là quá mức cần thiết.

Tuy nhiên ... Hãy nhớ đặt câu hỏi "Liệu nó có luôn duy trì ở quy mô nhỏ không?" :-)

Answer 4

Tôi đồng ý rằng việc sử dụng dịch vụ web trong ứng dụng web quy mô nhỏ sẽ thêm một lớp phức tạp mà dường như không hợp lý. Hầu hết các giải pháp, internet và mạng nội bộ của tôi, 10-50 người dùng, không sử dụng dịch vụ web. Tôi vui mừng những người khác cảm thấy như vậy ... Tôi nghĩ rằng tôi là người duy nhất.

Answer 5

Chỉ vì công cụ tạo ra một loạt các nhánh không có nghĩa là nó là một sử dụng tốt. WS- * trội trong các tình huống mà bạn hiển thị các dịch vụ cho các bên bên ngoài. Điều này có nghĩa là mỗi hoạt động phải dựa trên mức độ chi tiết của quy trình kinh doanh trái ngược với truy cập dữ liệu. Có thể sử dụng vô số các tiêu chuẩn để mô tả các khía cạnh khác nhau của hợp đồng của bạn một cách chi tiết và ngăn xếp WS hoàn toàn tương thích với giả thuyết có thể lấy đi rất nhiều đau đớn từ các nhà phát triển bên thứ ba và thậm chí cho phép điểm và nhấp chuột được kích hoạt tích hợp a'la Yahoo Pipes. Với các điều khiển quản trị tốt, bạn có thể phát triển giao diện công khai của mình và quản lý khả năng tương thích ngược khi cần.

Tất cả điều này là bên cạnh không thể được tạo tự động. C# stub generator chỉ biết giao diện vật lý của lớp của bạn, nhưng không có bất kỳ ý tưởng nào về ngữ nghĩa liên quan. Xem this paper để biết thêm chi tiết.

Nếu bạn đang xây dựng một trang web, sau đó xây dựng một trang web. Nếu bạn muốn nhắn tin không đồng bộ bên trong ứng dụng của mình, hãy sử dụng MSMQ. Nếu bạn muốn hiển thị dữ liệu cho khách hàng nội bộ, hãy sử dụng POX. Nếu bạn cần định dạng thông báo nhị phân hiệu quả, hãy kiểm tra số Protocol Buffers của Google hoặc nếu bạn cần RPC kiểm tra Hessian for C# hoặc DCOM.

Dịch vụ web là một giải pháp tích hợp hạt thô. Chúng cứng nhắc, chúng chậm hơn so với các lựa chọn thay thế, chúng mất quá nhiều công sức để làm tốt (và khi không được thực hiện tốt thì bên cạnh vô nghĩa).

Để tóm tắt: "Khi nào thì dịch vụ web không sử dụng?" - bất cứ lúc nào bạn có thể đi mà không có nó

Answer 6

Nick Harrison, một nhà phát triển rực rỡ tại Charlotte, gợi ý những kịch bản mà sử dụng một dịch vụ web có ý nghĩa:

• Trên một trang trại Web, nơi có rất nhiều máy chủ web hosting (các) trang web, tất cả trỏ tới (các) dịch vụ web đang chạy trên một máy chủ web khác. Điều này cho phép phân phối tải trên nhiều máy chủ.
• Khách hàng/máy chủ, nơi Windows tạo ứng dụng có thể gọi dịch vụ web.
• Cheo nền
• Đi qua một tường lửa

Answer 7

Đối với một ứng dụng web quy mô nhỏ tôi nghĩ rằng việc sử dụng các dịch vụ web thường là khá một ý tưởng tốt, bạn có thể sử dụng nó để dễ dàng tách các máy chủ web từ dữ liệu tầng. Với các yêu cầu phát triển thẳng và công cụ tuyệt vời, tôi không thấy vấn đề.

Tuy nhiên không dịch vụ web sử dụng trong các tình huống sau:

• Khi bạn phải sử dụng Http như việc vận chuyển và Xml serialization dữ liệu của bạn và bạn cần nhiều bit dữ liệu khác nhau, đồng bộ và thường xuyên. Cho dù REST hoặc SOAP hay WS- * bạn sẽ phải chịu các vấn đề hiệu năng. Càng nhiều cuộc gọi bạn thực hiện thì hệ thống của bạn càng chậm.Nếu bạn muốn khối dữ liệu có kích thước trung bình ít thường xuyên hơn, không đồng bộ và bạn có thể sử dụng TcpIp thẳng (ví dụ: Wcf netTcpBinding), bạn sẽ tốt hơn.
• Khi bạn cần truy vấn và tham gia dữ liệu từ dịch vụ web của bạn với các nguồn dữ liệu khác, chứ không phải thúc đẩy cho một kho dữ liệu có thể được dân cư với dữ liệu củng cố đúng cách và hợp lý từ khắp các enterprize

Đây là kinh nghiệm của tôi , hy vọng nó giúp.