Kata pengantar
Dalam beberapa tahun terakhir, adaptasi multi-terminal berbasis web dari berbagai situs telah berjalan lancar, dan solusi yang mengandalkan berbagai teknologi juga telah dikembangkan di antara industri. Seperti desain responsif berdasarkan browser asli CSS3 Media Query, solusi "adaptasi cloud" berdasarkan pengaturan ulang cloud cerdas, dll. Artikel ini terutama membahas solusi adaptasi multi-terminal berdasarkan pemisahan ujung depan dan belakang.
Tentang pemisahan front-end
Mengenai solusi pemisahan front-end, ada penjelasan yang sangat jelas dalam "pemikiran dan praktik pemisahan front-end berdasarkan nodejs (i)". Kami memperkenalkan nodeJs sebagai lapisan rendering antara antarmuka server dan browser. Karena lapisan NodeJS sepenuhnya terpisah dari data dan tidak perlu peduli dengan banyak logika bisnis, itu sangat cocok untuk pekerjaan adaptasi multi-terminal di lapisan ini.
Deteksi ua
Hal pertama yang harus dipecahkan dalam adaptasi multi-terminal adalah masalah deteksi UA. Untuk permintaan selesai, kita perlu mengetahui jenis perangkat ini untuk mengeluarkan konten yang sesuai dengannya. Sekarang ada pustaka fitur agen pengguna yang sangat matang dan alat deteksi yang kompatibel dengan sejumlah besar perangkat di pasaran. Berikut adalah daftar yang disusun oleh Mozilla. Di antara mereka, ada keduanya yang berjalan di sisi browser dan yang berjalan di lapisan kode sisi server. Beberapa alat bahkan menyediakan modul Nginx/Apache, yang bertanggung jawab untuk mem -parsing informasi UA untuk setiap permintaan.
Sebenarnya kami merekomendasikan yang terakhir. Solusi berdasarkan pemisahan front-end menentukan bahwa probe UA hanya dapat berjalan di sisi server, tetapi ini bukan solusi yang cukup ramah jika kode probe dan pustaka fitur digabungkan dalam kode bisnis. Kami memajukan perilaku ini dan menggantungnya di Nginx/Apache. Mereka bertanggung jawab untuk mem -parsing informasi UA untuk setiap permintaan dan kemudian meneruskannya ke kode bisnis melalui header HTTP.
Ada beberapa manfaat untuk melakukan ini:
Kode kami tidak perlu lagi memperhatikan bagaimana UA parse, keluarkan saja informasi yang diuraikan dari lapisan atas. Jika ada beberapa aplikasi di server yang sama, informasi UA yang diuraikan oleh Nginx yang sama dapat digunakan bersama -sama, menyimpan kerugian resolusi antara aplikasi yang berbeda.
Solusi deteksi UA berdasarkan nginx yang dibagikan oleh tmall
Server web Tengine Taobao juga menyediakan modul serupa NGX_HTTP_USER_AGENT_MODULE.
Perlu disebutkan bahwa ketika memilih alat deteksi UA, pemeliharaan pustaka fitur harus dipertimbangkan. Karena ada semakin banyak jenis peralatan baru di pasaran, setiap perangkat akan memiliki agen pengguna independen, sehingga pustaka fitur harus memberikan pembaruan yang baik dan strategi pemeliharaan untuk beradaptasi dengan perubahan peralatan.
Beberapa adaptasi yang dibangun ke dalam mode MVC
Setelah mendapatkan informasi UA, kita perlu mempertimbangkan jika adaptasi terminal dilakukan berdasarkan UA yang ditentukan. Bahkan di lapisan NodeJS, meskipun sebagian besar logika bisnis hilang, kami masih membagi internal menjadi tiga model: model/pengontrol/tampilan.
Mari kita gunakan diagram di atas terlebih dahulu untuk menganalisis beberapa solusi adaptasi multi-terminal yang ada.
Adaptasi yang dibangun di atas pengontrol
Solusi ini harus menjadi cara paling sederhana dan paling kasar untuk menghadapinya. Lewati URL yang sama ke lapisan kontrol yang sama melalui router. Lapisan kontrol kemudian mendistribusikan data dan model logika ke tampilan yang sesuai (tampilan) melalui informasi UA untuk rendering, dan lapisan rendering menyediakan templat yang beradaptasi dengan beberapa terminal sesuai dengan pra-konvensi.
Keuntungan dari solusi ini adalah mempertahankan kesatuan data dan lapisan kontrol, dan logika bisnis dapat diterapkan pada semua terminal hanya sekali. Namun, skenario ini hanya cocok untuk aplikasi interaktif rendah seperti halaman tampilan. Setelah bisnis lebih kompleks, pengontrol masing -masing terminal mungkin memiliki logika pemrosesan sendiri. Jika mereka masih berbagi pengontrol, itu akan membuat controller sangat membengkak dan sulit dipelihara, yang tidak diragukan lagi merupakan pilihan yang salah.
Adaptasi yang dibangun di atas router
Untuk menyelesaikan masalah di atas, kita dapat membedakan perangkat pada router dan mendistribusikannya ke pengontrol yang berbeda untuk terminal yang berbeda:
Ini juga merupakan salah satu solusi yang paling umum, sebagian besar dimanifestasikan dalam menggunakan serangkaian aplikasi terpisah untuk terminal yang berbeda. Misalnya, ketika beranda Taobao PC dan versi WAP beranda Taobao, ketika perangkat yang berbeda mengunjungi www.taobao.com, server akan mengarahkan kembali ke beranda Taobao versi WAP atau versi PC beranda Taobao melalui kontrol router. Mereka adalah dua set aplikasi yang sepenuhnya independen.
Namun, solusi ini tidak diragukan lagi membawa masalah yang data dan bagian dari logika tidak dapat dibagikan. Berbagai terminal tidak dapat berbagi data dan logika bisnis yang sama, menghasilkan banyak pekerjaan berulang dan tidak efisien.
Untuk mengurangi masalah ini, seseorang mengusulkan solusi yang dioptimalkan: dalam set aplikasi yang sama, setiap sumber data masih disarikan ke dalam setiap model, dan diberikan kepada pengontrol terminal yang berbeda untuk kombinasi:
Solusi ini memecahkan masalah yang tidak dapat dibagikan oleh data sebelumnya. Pada pengontrol, setiap terminal masih independen satu sama lain, tetapi dapat menggunakan batch sumber data yang sama secara bersamaan. Setidaknya tidak perlu mengembangkan antarmuka independen untuk tipe terminal dalam data.
Dalam dua solusi berbasis router di atas, karena independensi pengontrol, masing-masing terminal dapat menerapkan logika interaktif yang berbeda untuk halamannya sendiri, memastikan fleksibilitas yang cukup untuk setiap terminal itu sendiri, yang juga merupakan alasan utama mengapa sebagian besar aplikasi mengadopsi solusi ini.
Adaptasi yang dibangun di atas lapisan tampilan
Ini adalah solusi yang digunakan untuk halaman pemesanan taobao, tetapi perbedaannya adalah bahwa halaman pemesanan menempatkan lapisan rendering keseluruhan di sisi browser, daripada lapisan nodeJS. Namun, apakah itu browser atau nodeJs, ide desain keseluruhan masih sama:
Dalam solusi ini, router, controller, dan model tidak perlu memperhatikan informasi perangkat, dan penilaian tipe terminal sepenuhnya diserahkan ke lapisan tampilan untuk diproses. Modul utama dalam gambar adalah "View Factory". Setelah model dan controller melewati data dan rendering logika, mereka menggunakan pabrik tampilan untuk mengambil komponen spesifik dari sekelompok komponen yang telah ditetapkan berdasarkan informasi perangkat dan status lainnya (bukan hanya informasi UA, tetapi juga lingkungan jaringan, area pengguna, dll.) Dan kemudian menggabungkannya ke halaman akhir.
Solusi ini memiliki beberapa keunggulan:
Lapisan atas tidak perlu memperhatikan informasi perangkat (UA). Video beberapa terminal masih ditangani oleh lapisan tampilan yang pada akhirnya menunjukkan hubungan terbesar. Ini bukan hanya adaptasi multi-terminal, tetapi di samping informasi UA, setiap komponen tampilan juga dapat menentukan templat mana outputnya sesuai dengan status pengguna, seperti menyembunyikan gambar secara default pada kecepatan jaringan rendah dan outputting aktivitas spanduk di area yang ditentukan. Template yang berbeda dari setiap komponen tampilan dapat memutuskan apakah akan menggunakan data yang sama dan logika bisnis atas kebijakan Anda sendiri, memberikan metode implementasi yang sangat fleksibel.
Tetapi jelas bahwa solusi ini juga yang paling kompleks, terutama ketika mempertimbangkan beberapa skenario aplikasi interaktif, router dan pengontrol mungkin tidak dapat tetap begitu murni. Khusus untuk beberapa bisnis dengan integritas yang relatif kuat, yang tidak dapat dibagi menjadi komponen sendiri, solusi ini mungkin tidak berlaku; Dan untuk beberapa bisnis sederhana, menggunakan arsitektur ini mungkin bukan pilihan terbaik.
Meringkaskan
Solusi di atas masing -masing tercermin dalam satu atau lebih bagian dari model MVC. Jika satu solusi tidak memenuhi kebutuhan dalam bisnis, beberapa solusi dapat diadopsi secara bersamaan. Atau dapat dipahami bahwa kompleksitas dan atribut interaktif dalam bisnis menentukan solusi adaptasi multi-terminal mana yang lebih cocok untuk produk.
Dibandingkan dengan skema desain responsif berbasis browser, karena sebagian besar deteksi terminal dan rendering logika dimigrasi ke server, beradaptasi di lapisan nodejs tidak diragukan lagi membawa kinerja yang lebih baik dan pengalaman pengguna; Selain itu, dibandingkan dengan masalah kualitas konversi yang disebabkan oleh beberapa skema yang disebut "adaptasi cloud", mereka tidak akan ada dalam skema "disesuaikan" berdasarkan pemisahan front-end. Solusi adaptasi untuk pemisahan ujung depan dan belakang memiliki keunggulan alami dalam aspek -aspek ini.
Akhirnya, untuk beradaptasi dengan kebutuhan adaptasi yang lebih fleksibel dan kuat, solusi adaptasi berdasarkan pemisahan front-end akan menghadapi lebih banyak tantangan!