Cara mengurangi kopling ketat antara dua sumber data

Saya mengalami kesulitan menemukan solusi yang tepat untuk masalah arsitektur berikut.

Dalam pengaturan kami (digambarkan di bawah) kami memiliki 2 sumber data, di mana sumber data A adalah sumber utama untuk item jenis Foo. Ada sumber data sekunder yang dapat digunakan untuk mengambil informasi tambahan di Foo; namun informasi ini tidak selalu ada.

Selanjutnya, sumber data A dapat digunakan untuk mengambil item dari tipe Bar. Namun, setiap Bar mengacu pada Foo. Kesulitan di sini adalah bahwa setiap Bar harus merujuk ke Foo yang, jika tersedia, juga mengandung informasi yang ditambah oleh sumber data B.

Pertanyaan saya adalah: bagaimana cara menghapus kopling ketat antara SubsystemA.1 dan DataSourceB?

Saya membuat aplikasi dengan banyak arsitektur data yang sama di belakangnya; kami memiliki basis data SQL di tempat yang berisi sebagian besar informasi internal dan otomatisasi sehari-hari, dan kemudian layanan cloud pihak ketiga yang digunakan untuk penjualan, manajemen akun, personel lapangan, dll. Helpdesk memerlukan informasi dari keduanya mengenai lokasi fisik klien dan peralatan, dan telah mendapatkannya dari dua aplikasi yang berbeda sampai saya melangkah.

Yang panjang dan pendek adalah bahwa satu sumber data perlu memiliki referensi ke catatan yang lain. Dalam kasus kami, data cloud pihak ketiga berisi referensi ke data di tempat karena pengaturan itulah yang paling kami kontrol. Sekarang, dengan ID untuk catatan dari kedua sumber data, kita bisa mendapatkan data dari keduanya; dengan ID cloud, kami menarik catatan dari cloud, mendapatkan ID tamu, dan menarik data tamu. Dengan ID di tempat, kami menyurvei kedua sumber data berdasarkan ID itu.

Dalam sistem saya, saya tidak membuat salah satu objek menjadi anak lain di lapisan domain; setiap penggunaan data dari kedua toko harus mempertahankan dua instance objek. Tidak ada yang dijamin ada, itulah sebabnya saya melakukannya dengan cara itu; aplikasi hanya dapat bekerja dengan data cloud, atau dengan data di tempat, atau keduanya, dengan lebih banyak keterbatasan semakin sedikit data yang dimilikinya.

Namun, itu tidak sulit untuk diubah, terutama jika Anda yakin bahwa satu sisi akan selalu ada; cukup sertakan properti dalam objek yang mewakili sisi yang datanya akan selalu ada, yaitu tipe objek yang mewakili catatan penyimpanan data lainnya. "Penggabungan" yang lebih maju dari dua grafik menjadi satu adalah mungkin.

Pengaturan semacam ini tentu harus digabungkan pada tingkat tertentu. Anda dapat memiliki DAL yang dapat berinteraksi dengan kedua penyimpan data, atau Anda dapat mengelompokkan DAL, satu per penyimpanan data, dan memiliki lapisan yang lebih tinggi seperti Pengontrol mendapatkan data dari masing-masing dan menggabungkannya. Tetapi, pada tingkat tertentu, program Anda harus memiliki kecerdasan untuk menyatukan data dua sumber data yang berbeda ini.

Anda dapat mengurangi kopling yang dibutuhkan dalam kebanyakan kasus dengan mengabstraksikan detail dari mana data berasal. Jika Anda mendapatkan data dari layanan web, yang diberikan kepada Anda sebagai instance dari kelas yang dihasilkan, maka pasang konverter untuk membuat salinan mendalam dari kelas layanan menjadi sesuatu yang Anda kontrol, yang tidak perlu diubah jika data sumber tidak (hanya jika skema itu).

Sekarang, ini bisa menjadi usaha besar; cloud yang kami gunakan memiliki lusinan kelas domain, beberapa di antaranya memiliki ratusan bidang data, dan - inilah kicker - Anda bisa dengan mudah harus membuat perubahan besar pada tipe data abstrak untuk mengakomodasi perpindahan ke cloud yang berbeda atau remote lain sumber data. Untuk alasan itu, saya tidak repot-repot; Saya menggunakan domain layanan web yang dihasilkan secara langsung, dan sekarang setelah perubahan dari cloud ke data di luar kantor (tetapi di bawah kendali kami) menjulang, detail yang masih belum saya ketahui, saya hanya berencana untuk mengubah formulir dan kerangka kode aplikasi, yang merupakan tempat data "digabungkan", untuk mencerminkan skema baru dan / atau objek data. Ini adalah pekerjaan besar dengan cara apa pun Anda mengirisnya.

Salah satu cara untuk mengatasinya adalah dengan membuat sumber data teragregasi yang berisi data dari kedua sumber data di satu tempat. Pekerjaan akan berjalan secara berkala untuk memeriksa perubahan sumber Adan B, dan menulis "delta" ke sumber data agregat Anda. Ini akan mengubah dua sumber data yang digabungkan secara ketat menjadi satu sumber data yang koheren.

Beberapa hal dapat mencegah Anda mengambil pendekatan ini:

• Jumlah data mungkin mahal - Salinan lengkap Adan Bperlu dibuat, menggandakan persyaratan ruang.
• Data harus live - Akan ada periode antara waktu data di sumber telah berubah dan pekerjaan agregasi telah menyebar ke sumber yang diagregasi.
• Anda perlu merekonsiliasi data dengan sumber asli - Tugas memindahkan perubahan kembali ke tempat asalnya menjadi jauh lebih kompleks jika Anda mengambil pendekatan ini.

Tampaknya di tingkat atas ada dua jenis: Foo dan Bar, dan Anda hanya memiliki dua tindakan tingkat atas: findFoo(...)dan findBar(...). Itu adalah antarmuka ke lapisan I / O.

Deskripsi Anda dari sumber data menunjukkan bahwa ada dua metode di A: findFoodan findBardan satu metode pada B: findFooAuxiliaryInformation. Dalam findFooAnda akan perlu untuk menggabungkan informasi dari A dan B.

Saya tidak yakin apa "kopling ketat" yang Anda maksud. Ada tiga jenis data yang terdapat dalam dua dataset: Bar, Foo, dan FooAuxData. Kopling antara Foodan FooAuxDatamelekat pada data input, dan tidak dapat dikurangi. Tetapi kopling itu harus muncul hanya dalam findFoometode. Itu yang terbaik yang bisa Anda lakukan. Persyaratan diterapkan di satu tempat. Jika berubah, Anda harus mengubah kode itu.

Kamu tidak bisa

Jika saya mengerti dengan benar, Foodan Barberasal dari dsA. BarMilik Foos.
Lebih disukai, Anda tidak ingin Barditugaskan ke Foo, kecuali jika Footelah dilengkapi dengan Foo.enhancedInfoyang berasal dari dsB.

Preferensi Anda untuk menugaskan Barkepada Foos adalah apa yang membuat kopling ketat Anda. Saya akan memenuhi syarat itu sebagai "tantangan persyaratan" yang memaksa Anda menempuh jalan tertentu.

Jadi tantangan teknisnya adalah yang dsBmungkin atau mungkin tidak memiliki informasi tentang apa pun yang diberikan Foodan yang dsBbahkan mungkin tidak tersedia.

Anda perlu memutuskan seberapa keras dan cepat preferensi itu untuk yang Foo.enhancedInfosebenarnya. Berdasarkan persyaratan itu, Anda dapat memutuskan untuk memberikan objek Foo+ Bar, atau tidak. Mengizinkan yang tidak disempurnakan Foountuk diberikan hanya mempersulit logika dan memberi tahu saya bahwa preferensi tidak seketat yang mungkin muncul. Tentukan varian apa dari Foo,, Foo.enhanceddan Baraplikasi Anda yang dapat didukung dan Anda akan memiliki jawaban pamungkas.

Ada hal-hal lain yang dapat Anda lakukan untuk memindahkan Fooinformasi terkait lebih dekat bersama-sama, dan itu mungkin menyelesaikan beberapa masalah ini. Cara pertanyaan Anda diutarakan, sepertinya Anda berurusan dengan masalah di tingkat objek data dan Anda mungkin tidak dapat mempertimbangkan perubahan tipe infrastruktur.

Jika data dalam sumber data B tidak dapat berdiri sendiri, Anda mungkin ingin memindahkannya ke sumber data A jika memungkinkan.

Jika mereka independen tetapi terkait, Anda harus melihat ke dalam virtualisasi data . Ini akan memungkinkan aplikasi memperlakukan data sebagai satu set (bila perlu) secara agnostik. Bergantung pada platform Anda, mungkin akan ada kerangka / pustaka yang ada yang dapat membantu Anda menerapkan ini.