WCF / SOA - Mengapa saya harus membuat objek parameter untuk permintaan sederhana


12

Perusahaan kami memulai inisiatif SOA yang cukup besar. Kami melakukan banyak hal dengan benar: ada komunikasi yang baik; uang untuk alat-alat yang sesuai; dan kami telah membawa beberapa keahlian yang baik untuk membantu kami dengan transisi.

Kami mencoba mengembangkan standar yang dapat kami ikuti sebagai sebuah kelompok, dan salah satu standar yang diusulkan sedikit mengganggu saya:

Kami telah membuat standar pada pola di mana setiap operasi mengambil objek permintaan dan mengembalikan objek respons.

Saya menyadari bahwa ini kurang lebih merupakan pendekatan standar bagi banyak orang, tetapi saya bertanya mengapa saya harus repot? (Aku tidak begitu baik dengan kebijaksanaan yang diterima, aku butuh alasan).

Sebagian besar layanan yang akan saya sediakan adalah pengambilan metadata organisasi sederhana. Misalnya, cari kebijakan keamanan untuk pengguna tertentu. Ini membutuhkan id pengguna dan tidak ada yang lain. Standar memberi tahu saya bahwa saya harus membungkus permintaan ini dalam suatu objek dan membungkus kebijakan yang dikembalikan dalam objek respons.

Kegelisahan saya diperkuat oleh pandangan pada WSDL yang dihasilkan dari kontrak kami. WCF menghasilkan pesan permintaan dan respons secara otomatis dan bahkan membungkus objek permintaan / respons.

Saya sepenuhnya memahami bahwa jika Anda membuat permintaan yang kompleks maka objek input yang kompleks diperlukan. Itu yang akan Anda lakukan bahkan jika layanan tidak terlibat.

Pertanyaan saya adalah mengapa saya harus membungkus permintaan dan tanggapan secara otomatis ketika:

  • Itu membuat layanan sederhana kurang ekspresif
  • Anda tetap akan melakukannya untuk layanan yang kompleks
  • WCF tetap membuat pesan permintaan / respons

Saya telah menemukan argumen berikut yang mendukung pendekatan ini:

Ini mendukung versi dengan memungkinkan parameter opsional untuk dimasukkan ke objek permintaan.

Kembali pada hari itu, saya melakukan sedikit COM, dan saya akan menganggap ini hampir anti-pola untuk versi. Untuk beberapa hal, saya kira itu akan membantu, tapi saya berharap di mana itu akan membantu, Anda sudah memiliki objek parameter.

Ini memungkinkan data umum dan perilaku diisolasi ke kelas dasar

Yang ini membawa beberapa berat dengan saya.

Ini menjauhkan orang dari perilaku gaya RPC dan menuju perilaku pengiriman pesan

Saya sudah membaca ini di situs Microsoft dan mendengarnya dari guru kami, tetapi saya masih belum memiliki gagasan yang jelas tentang apa artinya atau mengapa itu berharga. Apakah antarmuka yang terlihat alami membuat orang cenderung lupa bahwa mereka memanggil layanan jarak jauh?

Saya sedang melihat refactoring tanda tangan mungkin 300 metode, jadi ini adalah jumlah rasa sakit yang tidak sepele. Saya penggemar berat konsistensi dalam implementasi, jadi saya bersedia untuk menanggung rasa sakit, itu hanya akan membantu untuk mengetahui bahwa semuanya akan sia-sia pada akhirnya.

Jawaban:


3

Saya pikir versi mungkin adalah argumen terbaik. Ketika Anda memiliki kontrak operasi yang sudah ada seperti

int GetPersons(int countryId);

yang ingin Anda tingkatkan, misalnya dengan filter lain nanti

int GetPersons(int countryId, int age);

Anda harus menulis kontrak operasi baru dan dengan nama baru karena harus unik. Atau Anda akan menyimpan nama dan menerbitkan v2 baru dari layanan Anda dengan v1 lama masih ada untuk kompatibilitas.

Jika Anda membungkus parameter menjadi objek Anda selalu dapat memperluasnya dengan parameter default / opsional dan semua klien Anda yang ada tidak akan terpengaruh ketika Anda menggunakan kembali kontrak operasi yang sama.

Namun saya juga mendesak untuk memberi nama objek Anda dengan tepat. Bahkan jika itu hanya membungkus int, jika Anda mulai dengan IntMessageatau sesuatu yang serupa Anda tidak melakukan kebaikan untuk memperpanjangnya. Anda harus menamainya misalnya PersonFiltermulai dari awal yang berarti Anda harus berpikir sedikit tentang apa yang harus diharapkan oleh panggilan layanan ini sebagai parameter secara semantik dan oleh karena itu apa yang seharusnya dilakukan. Mungkin (dan itu mungkin sangat tidak jelas) yang akan membantu dalam mengembangkan layanan yang tepat dan mempertahankan API berukuran layak.

Ini memungkinkan data umum dan perilaku diisolasi ke kelas dasar

Itu sesuatu yang harus diwaspadai. Kontrak warisan dan data tidak sejalan dengan itu. Ini memang berhasil, tetapi Anda harus menentukan semua subtipe kontrak yang diketahui yang dapat melewati kawat, jika tidak, serializer kontrak data gagal mengeluh tentang jenis yang tidak dikenal.

Tapi apa yang bisa Anda lakukan (tapi mungkin masih tidak boleh, saya masih ragu tentang ini) adalah menggunakan kembali pesan yang sama di antara berbagai layanan. Jika Anda meletakkan kontrak data dalam dll yang terpisah, Anda dapat membagikannya di antara klien dan layanan dan Anda tidak perlu mengonversi antar jenis ketika Anda memanggil layanan berbeda yang pada dasarnya mengharapkan pesan yang sama. Misalnya Anda membuat PersonFilter dan mengirimkannya ke satu layanan untuk mendapatkan daftar filter orang dan kemudian ke layanan lain dan memiliki objek yang sama pada klien. Saya tidak dapat menemukan contoh dunia nyata yang baik untuk itu dan bahayanya selalu bahwa perpanjangan kontrak data tidak cukup umum untuk semua layanan yang menggunakan kontrak ini.

Secara keseluruhan, selain versi, saya tidak bisa menemukan alasan pembunuh untuk melakukannya juga.


Saya pikir alasan mengapa saya mengambil
Andy Davis

(maaf, antarmuka komentar memberi saya kesedihan) Terima kasih telah menjawab. Saya pikir alasan mengapa saya mengambil argumen versi dengan sebutir garam adalah bahwa jika Anda menambahkan argumen baru Anda mungkin mengubah semantiknya. Jika (seperti dalam contoh Anda) Anda baru saja menambahkan usia, semantik mungkin untuk pencarian dan Anda memiliki "objek pencarian" di sana untuk memulai.
Andy Davis

Sekarang perhatikan contoh kebijakan keamanan saya. Mungkin kita memutuskan bahwa untuk menyediakan kebijakan keamanan dengan benar, kita perlu tahu tidak hanya pengguna, tetapi fasilitas tempat mereka bekerja. Ini lebih dari sekadar menambahkan argumen, kita telah mengubah semantik panggilan. Dengan asumsi bahwa kami entah bagaimana dapat menyediakan informasi ini untuk penelepon versi sebelumnya, saya pikir lebih masuk akal untuk versi kontrak layanan. Maka implementasi untuk versi lama dapat diisolasi dan Anda tidak akhirnya mencampur semantik lama dengan yang baru.
Andy Davis

0

Catatan Martin Fowler tentang Objek Transfer Data sesuai di sini, saya kira.

Saat Anda bekerja dengan antarmuka jarak jauh, seperti Remote Facade (388), setiap panggilannya mahal. Akibatnya, Anda perlu mengurangi jumlah panggilan, dan itu berarti Anda perlu mentransfer lebih banyak data dengan setiap panggilan. Salah satu cara untuk melakukan ini adalah dengan menggunakan banyak parameter. Namun, ini seringkali canggung untuk diprogram - memang, seringkali tidak mungkin dengan bahasa seperti Java yang hanya mengembalikan nilai tunggal.

Solusinya adalah membuat Objek Transfer Data yang dapat menampung semua data untuk panggilan tersebut. Itu harus serializable untuk pergi melintasi koneksi. Biasanya assembler digunakan di sisi server untuk mentransfer data antara DTO dan objek domain apa pun.

Hal yang sama berlaku untuk permintaan. Adapun RPC, dan mengapa itu buruk:

Apakah antarmuka yang terlihat alami membuat orang cenderung lupa bahwa mereka memanggil layanan jarak jauh?

Saya pikir itu benar, tetapi bukan alasan utama. Alasan lain untuk menghindari RPC adalah bahwa hal itu dapat mendorong klien dan layanan yang berpasangan erat.


Terima kasih atas masukannya, tetapi saya tidak berpikir bahwa diskusi DTO sangat relevan. Itu jumlah panggilan yang sama, dan jika Anda melihat WSDL, semuanya secara otomatis dikemas menjadi objek permintaan dan tanggapan. Konvensi ini tentang semantik yang terlihat , yaitu, orang harus menganggap ini sebagai permintaan & respons sebagai lawan panggilan metode jarak jauh.
Andy Davis

Apakah Anda ingin menguraikan RPC yang mendorong klien dan layanan yang berpasangan ketat? Saya tidak dapat melihat bahwa ini mempengaruhi layanan sama sekali. Untuk klien, saya juga tidak benar-benar melihat bagaimana sesuatu benar-benar berubah. Dalam kedua kasus, saya memiliki klien yang memegang proxy yang menjelaskan sejumlah operasi yang disediakan oleh layanan. Yang benar-benar mengimplementasikan sisi lain dari layanan bukanlah bisnis klien.
Andy Davis
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.