WCF / SOA - Tại sao tôi nên tạo các đối tượng tham số cho các yêu cầu đơn giản

Công ty chúng tôi đang bắt đầu một sáng kiến ​​khá lớn về SOA. Chúng tôi đang làm rất nhiều thứ đúng: có giao tiếp tốt; tiền cho công cụ khi thích hợp; và chúng tôi đã mang lại một số chuyên môn tốt để giúp chúng tôi chuyển đổi.

Chúng tôi đang cố gắng phát triển các tiêu chuẩn mà chúng tôi có thể theo một nhóm và một trong những tiêu chuẩn được đề xuất đang làm phiền tôi khá nhiều:

Chúng tôi đã chuẩn hóa mẫu mà mọi thao tác đều lấy một đối tượng yêu cầu và trả về một đối tượng phản hồi.

Tôi nhận ra rằng đây ít nhiều là một cách tiếp cận tiêu chuẩn cho nhiều người, nhưng tôi đang hỏi tại sao tôi phải bận tâm? (Tôi không tốt lắm với sự khôn ngoan nhận được, tôi cần một số lý do tại sao).

Hầu hết các dịch vụ mà tôi sẽ cung cấp là truy xuất siêu dữ liệu tổ chức đơn giản. Ví dụ: tìm chính sách bảo mật cho một người dùng cụ thể. Điều này cần một id người dùng và không có gì khác. Tiêu chuẩn cho tôi biết rằng tôi nên bọc yêu cầu này trong một đối tượng và bọc chính sách được trả về trong một đối tượng phản hồi.

Sự khó chịu của tôi được khuếch đại bằng cách nhìn vào WSDL được tạo ra từ các hợp đồng của chúng tôi. WCF tự động tạo thông điệp yêu cầu và phản hồi và kết thúc tốt đẹp ngay cả đối tượng yêu cầu / phản hồi.

Tôi hoàn toàn hiểu rằng nếu bạn đang thực hiện một yêu cầu phức tạp thì một đối tượng đầu vào phức tạp sẽ được bảo hành. Đó là những gì bạn sẽ làm ngay cả khi các dịch vụ không liên quan.

Câu hỏi của tôi là tại sao tôi nên tự động gói yêu cầu và trả lời khi:

• Nó làm cho các dịch vụ đơn giản ít biểu cảm
• Dù sao bạn cũng sẽ làm điều đó cho một dịch vụ phức tạp
• WCF vẫn tạo một thông báo yêu cầu / phản hồi

Tôi đã tìm thấy các đối số sau đây có lợi cho phương pháp này:

Nó hỗ trợ phiên bản bằng cách cho phép các tham số tùy chọn được đưa vào đối tượng yêu cầu.

Trước đây, tôi đã thực hiện một chút COM và tôi sẽ coi đây gần như là một mô hình chống phiên bản. Đối với một số thứ, tôi cho rằng nó sẽ giúp ích, nhưng tôi hy vọng rằng nó sẽ giúp được gì, dù sao bạn cũng đã có một đối tượng tham số.

Nó cho phép dữ liệu và hành vi chung được tách biệt với lớp cơ sở

Điều này mang một số trọng lượng với tôi.

Nó giúp mọi người tránh xa hành vi kiểu RPC và hướng tới hành vi nhắn tin

Tôi đã đọc nó trên trang web của Microsoft và nghe nó từ guru của chúng tôi, nhưng tôi vẫn không biết rõ ý nghĩa của chúng hoặc tại sao nó có giá trị. Có phải các giao diện tìm kiếm tự nhiên làm cho mọi người có xu hướng quên rằng họ đang gọi một dịch vụ từ xa?

Tôi đang xem xét tái cấu trúc chữ ký của có lẽ 300 phương pháp, vì vậy đây là một nỗi đau không hề nhỏ. Tôi là một fan hâm mộ lớn của sự nhất quán trong việc triển khai, vì vậy tôi sẵn sàng chịu đựng nỗi đau, điều đó sẽ giúp ích để biết rằng cuối cùng tất cả sẽ có giá trị.

Tôi nghĩ rằng phiên bản có lẽ là đối số tốt nhất. Khi bạn có một hợp đồng hoạt động như

int GetPersons(int countryId);

mà bạn muốn cải thiện, ví dụ như bởi một bộ lọc khác sau này

int GetPersons(int countryId, int age);

Bạn sẽ phải viết một hợp đồng hoạt động mới và với một tên mới vì nó phải là duy nhất. Hoặc bạn sẽ giữ tên và xuất bản v2 mới cho dịch vụ của mình với v1 cũ vẫn còn để tương thích ngược.

Nếu bạn bọc tham số vào một đối tượng, bạn luôn có thể mở rộng nó với các tham số mặc định / tùy chọn và tất cả các máy khách hiện tại của bạn sẽ không bị ảnh hưởng khi bạn sử dụng lại cùng một hợp đồng hoạt động.

Tuy nhiên tôi cũng mong muốn đặt tên cho các đối tượng của bạn một cách thích hợp. Ngay cả khi nó chỉ kết thúc một int, nếu bạn bắt đầu với IntMessagehoặc một cái gì đó tương tự, bạn sẽ không tự mình mở rộng nó. Bạn phải đặt tên cho nó, ví dụ PersonFilterngay từ đầu, điều đó có nghĩa là bạn phải suy nghĩ một chút về những gì cuộc gọi dịch vụ này sẽ mong đợi như là tham số về mặt ngữ nghĩa và do đó nó phải làm gì. Có lẽ (và đó là một điều rất mơ hồ có thể) sẽ giúp phát triển các dịch vụ phù hợp và duy trì API có kích thước khá.

Nó cho phép dữ liệu và hành vi chung được tách biệt với lớp cơ sở

Đó là điều cần thận trọng. Hợp đồng kế thừa và dữ liệu không đi cùng nhau. Nó hoạt động, nhưng bạn sẽ phải chỉ định tất cả các kiểu con đã biết của hợp đồng có thể đi qua dây, nếu không, bộ nối tiếp hợp đồng dữ liệu không phàn nàn về các loại không xác định.

Nhưng những gì bạn có thể làm (nhưng có lẽ vẫn không nên, tôi vẫn chưa quyết định điều này) là sử dụng lại các tin nhắn giống nhau giữa các dịch vụ khác nhau. Nếu bạn đặt các hợp đồng dữ liệu trong một dll riêng, bạn có thể chia sẻ rằng giữa máy khách và dịch vụ và bạn không cần phải chuyển đổi giữa các loại khi bạn gọi các dịch vụ khác nhau về cơ bản là cùng một thông điệp. Ví dụ: bạn tạo PersonFilter và gửi nó tới một dịch vụ để lấy danh sách bộ lọc của những người và sau đó đến một dịch vụ khác và có cùng các đối tượng trên máy khách. Mặc dù vậy, tôi không thể tìm thấy một ví dụ thực tế tốt cho điều đó và điều nguy hiểm luôn là việc gia hạn hợp đồng dữ liệu không đủ chung cho tất cả các dịch vụ sử dụng hợp đồng này.

Nhìn chung, ngoài phiên bản, tôi thực sự không thể tìm thấy lý do giết người để làm theo cách đó.

Ghi chú của Martin Fowler về Đối tượng truyền dữ liệu là phù hợp ở đây, tôi nghĩ vậy.

Khi bạn đang làm việc với một giao diện từ xa, chẳng hạn như Remote Facade (388), mỗi cuộc gọi đến nó đều đắt tiền. Do đó, bạn cần giảm số lượng cuộc gọi và điều đó có nghĩa là bạn cần chuyển nhiều dữ liệu hơn với mỗi cuộc gọi. Một cách để làm điều này là sử dụng nhiều tham số. Tuy nhiên, điều này thường gây khó khăn cho chương trình - thực sự, điều đó thường không thể xảy ra với các ngôn ngữ như Java chỉ trả về một giá trị duy nhất.

Giải pháp là tạo Đối tượng truyền dữ liệu có thể chứa tất cả dữ liệu cho cuộc gọi. Nó cần phải được tuần tự hóa để đi qua kết nối. Thông thường, một trình biên dịch được sử dụng ở phía máy chủ để truyền dữ liệu giữa DTO và bất kỳ đối tượng miền nào.

Điều tương tự có thể áp dụng cho các yêu cầu. Đối với RPC, và tại sao nó xấu:

Có phải các giao diện tìm kiếm tự nhiên làm cho mọi người có xu hướng quên rằng họ đang gọi một dịch vụ từ xa?

Tôi nghĩ đó là sự thật, nhưng không phải là lý do chính. Một lý do khác để tránh RPC là nó có thể khuyến khích các khách hàng và dịch vụ được liên kết chặt chẽ.