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

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.

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.

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.