Baru-baru ini, saya menemukan skenario aplikasi seperti itu. Suatu perusahaan telah menggunakan sistem yang dikembangkan oleh PowerBuilder selama bertahun-tahun, seiring dengan berkembangnya perusahaan, perusahaan tersebut memutuskan untuk mengubah sistem informasi lama dari C/S ke arsitektur B/S yang populer masalah muncul: Beberapa sistem asli memiliki entri data dalam jumlah besar, pencetakan laporan yang presisi, dan fungsi lainnya, dan pengguna sudah sangat terbiasa dengan pengoperasian semacam ini. Diharapkan sistem baru dapat mempertahankan fitur yang mudah digunakan ini dari sistem aslinya.
Saya pusing ketika mendengar pertanyaan ini. PB memiliki banyak kontrol yang kuat. Terlalu sulit untuk memindahkannya ke browser dan menggunakan halaman web untuk mensimulasikannya.
1. Mengapa sulit bagi B/S untuk memberikan pengalaman interaksi pengguna yang baik?
Ada beberapa masalah terbesar di sini:
(1) Protokol HTTP stateless
dapat langsung bertukar informasi antar formulir Windows melalui memori, tetapi sebagai dasar B/S komunikasi arsitektur Protokol HTTP tidak memiliki kewarganegaraan.
Jika browser dianggap sebagai tamu dan Server Web dianggap sebagai hotel, di bawah pengelolaan protokol HTTP, situasi ini akan terjadi: tidak peduli berapa kali tamu berkunjung, Server Web akan menganggapnya sebagai yang pertama- pengunjung waktu. Dengan cara ini, para tamu harus membawa dokumen identitas mereka setiap saat agar staf hotel dapat "memverifikasi identitas mereka".
Protokol HTTP yang tidak memiliki kewarganegaraan menyebabkan "pengabaian" terhadap Server Web. Meskipun hal ini dapat meningkatkan throughput Server Web, hal ini membawa masalah pada pengembangan sistem aplikasi. Karena seringkali banyak proses pemrosesan bisnis dalam sistem aplikasi yang pada dasarnya bersifat information-flow, yaitu data asli masuk dari satu ujung dan seharusnya sudah mengalami pemrosesan tertentu ketika keluar dari ujung yang lain informasi di seluruh proses bisnis akan hilang? Oleh karena itu, Berbagi informasi antar permintaan HTTP menjadi masalah yang merepotkan. Setiap sistem B/S harus memecahkan masalah ini. Microsoft memikirkan beberapa "trik jahat", seperti memanfaatkan sepenuhnya bidang tersembunyi di halaman web HTML, dan kemudian melakukan beberapa trik di Server Web, sehingga ASP.NET memiliki serangkaian teknologi untuk mempertahankan status di antara setiap permintaan HTTP: Sesi, Cookie, Status Tampilan, Profil, Aplikasi.
Namun permasalahan tersebut belum sepenuhnya terselesaikan. Misalnya, pada kotak dialog umum dalam sistem C/S yang mengumpulkan informasi masukan pengguna, terjadi pertukaran informasi antara formulir utama dan kotak dialog (dibagi menjadi dua jenis: modal dan non-modal. Kotak dialog sebelumnya adalah tidak ditutup. Formulir utama tidak dapat diaktifkan). Di bawah arsitektur B/S, karena setiap permintaan browser bersifat independen, pertukaran informasi langsung yang mirip dengan kotak dialog modal harus diterapkan antara dua jendela browser independen tahu apa yang harus dilakukan.
AJAX menggunakan metode berikut untuk "mensimulasikan" bentuk modal: "menggabungkan" bentuk utama dan kotak dialog menjadi satu. Kotak dialog adalah elemen div dalam HTML, yang biasanya disembunyikan dan ditampilkan saat diperlukan. Toolkit Kontrol AJAX Microsoft bahkan memiliki kontrol yang dirancang untuk fungsi ini. Ada banyak sekali trik seperti ini dalam pengembangan B/S.
Dapat dilihat bahwa banyak fungsi yang mudah diimplementasikan di C/S namun sangat sulit diimplementasikan di B/S.
(2) Lingkungan operasi khusus -
lingkungan operasi front-end dari sistem browser B/S adalah browser, yang memiliki banyak batasan. Ia tidak dapat melakukan banyak hal, seperti mengakses perangkat keras secara langsung (seperti printer), dan tidak dapat melakukan penuh penggunaannya. Misalnya, komputer baru saat ini semuanya dual-core. Bisakah Anda langsung menggunakan JavaScript dan HTML untuk menulis program multi-thread untuk memanfaatkan sepenuhnya kedua "core Pentium" ini?
Sistem C/S berjalan langsung di OS (beroperasi sistem) Di atas, Anda dapat memanggil semua fungsi yang disediakan oleh OS, dan batasan ini tidak ada.
(3) Bahasa pemrograman klien Web yang memalukan - JavaScript,
program C/S tradisional, dapat menggunakan berbagai macam bahasa pengembangan, terutama bahasa berorientasi objek arus utama seperti C++, Java, dan C#, yang merupakan kuat dan mudah digunakan, berbagai alat pengembangan tersedia dan sangat matang.
Sebaliknya, JavaScript, bahasa pemrograman yang paling umum digunakan di front-end B/S, tidak hanya tidak disukai, tetapi bahkan "dibenci" oleh banyak programmer, yang menganggap "pemrograman dengan JavaScript" sebagai sebuah tugas.
Mari kita lihat dua kekurangan utama JavaScript.
Pertama, kurangnya model pemrograman yang jelas dan terpadu.
Meskipun JavaScript memiliki nama Java dan menggunakan sintaksis serupa, itu tidak ada hubungannya dengan Java asli. Sayangnya, dia adalah anak itik jelek. Dia selalu ingin menjadi angsa, tapi dia tidak berharap orang lain tidak mempercayai idenya.
JavaScript menggunakan banyak objek, tetapi sangat tidak meyakinkan untuk mengatakan bahwa itu berorientasi objek (unit dasar dari pemrograman berorientasi objek adalah kelas). Misalnya, ia tidak memiliki kata kunci class yang mirip dengan bahasa berorientasi objek mainstream seperti C#. Ia memiliki fungsi satu per satu di mana-mana, sehingga sulit untuk mendefinisikan dengan jelas semua kode dalam bentuk kelas; pada saat yang sama, ia tidak terstruktur (unit dasar dari pemrograman terstruktur adalah sebuah fungsi ), karena browser menggunakan aliran saat menguraikan dokumen HTML. Hal ini menyebabkan beberapa kode JavaScript ditempatkan di luar fungsi dan dieksekusi langsung saat menguraikan dokumen HTML, sedangkan bagian lain dari kode yang ditempatkan dalam fungsi sebagian besar dijalankan dalam sebuah acara. -driven, yang menimbulkan masalah yang kompleks. Alur eksekusi program jauh lebih ringkas dibandingkan penggunaan pemanggilan fungsi secara terpadu dalam pemrograman yang murni terstruktur.
Dari sudut pandang ini, JavaScript memiliki karakteristik metode pemrograman berorientasi objek, terstruktur, dan tidak terstruktur, tetapi tidak memiliki model pemrograman yang jelas dan terpadu. Sulit untuk menulis kode dengan jelas struktur dan perawatan yang mudah. Banyak kebingungan datang.
Kedua, kelemahan lain dari JavaScript adalah lingkungan browsernya berjalan.
Karena alasan historis, browser yang berbeda, dan bahkan versi berbeda dari browser yang sama, memiliki model pemrograman yang kurang lebih berbeda. Oleh karena itu, kita harus menulis kode untuk mendeteksi jenis browser IE, dan Menulis set lain untuk FireFox. Ini sungguh merepotkan.
Permasalahan di atas hampir merupakan “cacat” “inheren” dari sistem arsitektur B/S. Kekurangan bawaan dilengkapi dengan pengasuhan, dan orang-orang telah menemukan banyak trik untuk mengatasi masalah ini. AJAX adalah bintang harapan yang membuat semua orang optimis.
2. Bintang Harapan - AJAX
Selama beberapa hari terakhir, saya telah mempelajari secara sistematis tentang kerangka kerja AJAX Microsoft. Saya menemukan bahwa kompleksitas kerangka kerja ini jauh melebihi perkiraan awal saya. Insinyur Microsoft yang merancang kerangka kerja AJAX mengeksplorasi secara mendalam potensi berbagai teknologi pengembangan Web, yang sebagian besar mengatasi masalah yang diangkat sebelumnya.
(1) Perluasan bahasa JavaScript:
Microsoft telah meningkatkan fitur JavaScript berorientasi objek dengan menyediakan Perpustakaan AJAX yang dienkapsulasi, yang dapat dengan mudah mengimplementasikan fungsi seperti pewarisan, pendefinisian antarmuka, pembuatan serial objek, peristiwa pemicu, tipe refleksi, dll., meskipun itu lebih kecil dari aslinya Masih ada kesenjangan antara bahasa berorientasi objek (seperti Java/C#), namun mampu mendandani JavaScript yang "jelek" menjadi sesuatu yang terlihat dianggap luar biasa.
(2) Secara signifikan meningkatkan fungsionalitas kode sisi browser.
Dengan dukungan Perpustakaan AJAX dan fungsionalitas JavaScript yang ditingkatkan, dan dengan dukungan browser itu sendiri, Anda dapat menulis skrip JavaScript di browser untuk dengan mudah membuat permintaan asinkron ke browser. server. , menyadari penyegaran sebagian halaman, dan dapat langsung menghubungi Layanan Web.
(3) Memperkenalkan metode pengembangan berbasis komponen (CBD).
Pengembangan berbasis komponen (CBD) telah lama menjadi metode pengembangan utama untuk sistem berorientasi objek. Meskipun SOA (arsitektur berbasis layanan) saat ini sangat populer, hal ini perlu dilakukan mencapai kematangan CBD. Sampai batas tertentu, hal ini memerlukan waktu.
Untuk JavaScript, apalagi SOA, sangat sulit mengimplementasikan CBD.
Untuk mewujudkan CBD, Microsoft telah "membuat perbaikan besar" pada JavaScript dan meningkatkan banyak fitur. Berdasarkan Perpustakaan Microsoft AJAX, pemrogram dapat mengembangkan tiga jenis komponen yang dapat digunakan kembali: None_Visual Component (komponen tak terlihat, setara dengan sistem berorientasi objek Beberapa). di antaranya menyediakan fungsi publik), Behavior (perilaku, memperluas fungsi kontrol Web yang ada), dan Control (Kontrol Web dengan elemen antarmuka visual).
Secara khusus, lusinan kontrol yang disediakan di AJAX Control ToolKit pada dasarnya mewujudkan simulasi B/S dari sebagian besar fitur antarmuka pengguna C/S, dan merupakan model penerapan model pemrograman baru ini.
Peningkatan Microsoft pada model pemrograman JavaScript memungkinkan insinyur perangkat lunak akhirnya mengembangkan kode klien Web menggunakan metode pengembangan CBD. Saya pikir ini adalah kemajuan.
(4) Peningkatan kemampuan sisi server
Untuk meningkatkan kemampuan kode sisi browser, kode tersebut harus dikoordinasikan melalui sisi server. AJAX sendiri didasarkan pada model pemrograman di mana Browser dan Server Web saling mendukung (Server Web menyediakan layanan data, dan Browser menyediakan objek XMLHttpRequest untuk mengeluarkan permintaan asinkron ke Server Web. Ketika data kembali, pemrogram dapat menulis kode dalam JavaScript ke menerapkan pemrosesan parsial dinamis pada halaman web.
Melalui Ekstensi AJAX, Microsoft telah meningkatkan fungsionalitas kerangka ASP.NET sisi server. Dan eksternalisasikan fungsi-fungsi yang umum digunakan ke dalam kontrol Web sederhana, seperti kontrol inti AJAX ScriptManager, UpdatePanel untuk menentukan area halaman yang dapat diperbarui, dan lusinan AJAX Control Toolkit untuk meningkatkan kontrol ASP.NET yang ada (yaitu, kontrol yang melekat pada pengendalian yang ada, yang tujuannya adalah untuk memperluas fungsi baru ke pengendalian yang ada).
Dengan kontrol ini, mengembangkan program front-end Web mirip dengan mendesain formulir di VB. Sekarang tidak hanya mungkin untuk menggambar antarmuka yang mirip dengan Windows Forms, tetapi juga dengan menggunakan permintaan asinkron AJAX dan teknologi penyegaran sebagian halaman, dan dengan kerja sama server Web, pengalaman pengguna dapat dipaksa masuk ke Windows Forms.
Tidak peduli berapa banyak orang yang meremehkan VB, gelombang mempopulerkan pemrograman visual yang dibawa oleh VB memang memiliki dampak yang luas. Dorongan Microsoft untuk pemrograman JavaScript ke langkah ini juga merupakan tren umum. Untuk meningkatkan efisiensi pengembangan Web, langkah ini harus diambil.
Namun, perlu dicatat bahwa tidak peduli berapa banyak yang "diisi ulang", bagaimanapun juga, itu adalah "kekurangan bawaan" dan masih sangat sulit bagi arsitektur B/S untuk mengungguli C/S dalam hal pengalaman pengguna. .
3. Masa depan: B/S atau C/S, siapa yang bertanggung jawab?
Karena kesederhanaan manajemen dan penerapannya, arsitektur B/S telah menjadi pilihan pertama bagi banyak sistem informasi saat ini pengalaman. Singkatnya, Ada persyaratan berikut:
(1) Antarmuka yang indah. B/S memiliki keuntungan dalam hal ini.
(2) Masukan yang mudah. Misalnya, banyak pengguna berharap untuk memasukkan data tanpa menggunakan mouse, atau secara otomatis mengisi data melalui klik sederhana. Hal ini sulit diterapkan dalam arsitektur B/S yang dapat mengatasi masalah ini sampai batas tertentu.
(3) Kecepatan kilat. Untuk C/S, ada banyak cara untuk mencapai kecepatan respon yang cepat, namun tidak mudah bagi B/S. Karena keterbatasan browser, sumber daya perangkat keras klien yang kuat hampir tidak digunakan. Selain itu, kecepatan jaringan merupakan penghambat arsitektur B/S. Kecuali jika bandwidth dapat meningkat dengan cepat, WWW akan menjadi World Wide Wait.
Meskipun C/S memiliki pengalaman pengguna yang baik, masalahnya adalah sulitnya mengembangkan sistem terdistribusi yang mencakup seluruh Internet. Selain itu, karena klien perlu diinstal, pembaruan sistem dan manajemen versi komponen menjadi masalah besar Selain itu, tidak seperti B dalam arsitektur /S, hanya masalah sisi server yang perlu dipertimbangkan. Dalam arsitektur C/S, karena banyak pengguna mengakses server pada saat yang sama, panggilan dan ketergantungan antar komponen menjadi rumit juga harus dipertimbangkan ketika berhadapan dengan akses multi-thread ke sumber daya bersama, pemrosesan transaksi, dll. Di sisi server, throughput sangat terbatas. Oleh karena itu, C/S sebagian besar dibangun di jaringan area lokal untuk penggunaan internal perusahaan.
Saat ini, B/S dan C/S pada dasarnya hidup berdampingan. Dengan meluasnya penerapan teknologi B/S seperti AJAX, B/S terus berada di atas angin, tetapi tidak mungkin untuk sepenuhnya "mengalahkan C/S". .
Yang lebih menarik adalah: Bagaimana perusahaan besar seperti Microsoft memandang prospek pengembangan B/S dan C/S?
Pengembang biasa seperti saya tidak memiliki kesempatan untuk berbicara langsung dengan para eksekutif Microsoft, tetapi kita bisa melihatnya dari perusahaan tersebut. jalur pengembangan produk. Berikut ini beberapa petunjuknya:
Microsoft tampaknya tidak percaya bahwa B/S mewakili arah perkembangan teknologi di masa depan. Sebaliknya, banyak dari tindakannya mengarah pada meninggalkan browser.
Pertama-tama, Microsoft telah menyederhanakan pengembangan dan penerapan C/S serta meluncurkan teknologi Smart Client, sehingga pembaruan program klien C/S dapat dilakukan secara otomatis tanpa intervensi manual.
Kedua, Microsoft bekerja keras untuk menjembatani kesenjangan antara B/S dan C/S. Saat merancang ASP.NET, Microsoft dengan tegas meninggalkan ASP, yang telah mencapai hasil yang baik, dan langsung mengadopsi metode pemrograman serupa "kontrol visual + berbasis peristiwa". ke VB. Bahkan halaman Web disebut "Formulir" - Formulir Web.
Ketiga, Microsoft mungkin menganggap AJAX sebagai teknologi transisi.
Microsoft lambat dalam mengambil tindakan terhadap AJAX hingga melihat popularitas AJAX yang pesat karena keberhasilan penerapan teknologi AJAX oleh Google dan perusahaan lain untuk meningkatkan pengalaman pengguna Web. Kemudian Microsoft mengambil tindakan dan menambahkan ekstensi AJAX ke ASP.NET Seluruh prosesnya jelas. Tindakannya tidak agresif, dan tidak banyak sumber daya yang diinvestasikan. Ini benar-benar berbeda dengan saat Microsoft dan Netscape meluncurkan perang browser. Namun, fakta bahwa ia memiliki Ekstensi AJAX bawaan sebagai konfigurasi standar di VS2008 dan secara langsung mengintegrasikan fungsi debugging JavaScript ke dalam IDE menunjukkan bahwa Microsoft masih menghadapi kenyataan dan mengakui bahwa AJAX memiliki posisi penting dan potensi pengembangan yang besar.
Faktanya, saya menganalisis bahwa ambisi Microsoft adalah untuk "menyatukan dunia", meninggalkan browser, dan sepenuhnya menyatukan B/S dan C/S.
Ini terlihat jelas di .NET 3.0/3.5.
Pertama-tama, Microsoft menggunakan WCF untuk menyatukan DCOM, .NET Remoting, dan teknologi lain yang terutama digunakan untuk C/S, mengintegrasikan banyak fitur pengembangan perusahaan yang awalnya berlokasi di COM+, bersama dengan teknologi Layanan Web yang terutama digunakan untuk arsitektur B/S, ke dalam Abstrak terpadu dan merangkumnya menjadi Layanan WCF yang dapat digunakan kembali. Jelas sekali bahwa Microsoft ingin mengubah model pengembangan sistem informasi dari CBD ke SOA (yaitu, sistem masa depan akan merakit layanan, bukan komponen).
Kedua, Microsoft meninggalkan model pemrograman program desktop Window yang sangat matang (Win32 API + pesan/event driver) dan memperkenalkan kerangka pemrograman WPF baru. Salah satu inovasi besar adalah munculnya XAML (Application Markup Language) yang sesuai dengan spesifikasi XML . XAML menggunakan file teks biasa berformat XML untuk menggambarkan antarmuka aplikasi.
Kita dapat dengan mudah membandingkan XAML dengan XHTML. Browser mem-parsing kode XHTML dan menghasilkan antarmuka web visual, sedangkan XAML diurai oleh mesin virtual .NET Framework. Di Vista, karena Vista secara langsung mengintegrasikan .NET Framework 3.0, Vista dapat dianggap sebagai browser super XAML untuk menghasilkan antarmuka pengguna dan mengimplementasikan semua fungsi aplikasinya.
Hasilnya, model pemrograman baru muncul. Baik itu sistem B/S atau C/S, metodenya terpadu: membaca kode XAML à parsing à menyajikan à menerima masukan pengguna à memproses data à menampilkan hasil.
Dalam model pemrograman ini, browser menjadi pengamat dan tidak lagi menjadi inti aplikasi klien.
Model pemrograman baru ini berjalan pada OS berfitur lengkap, bukan pada browser dengan fungsi terbatas. Perbedaannya sangat besar. Bagaimana fungsi browser yang berjalan di OS dibandingkan dengan OS itu sendiri!
Sekarang sistem operasi dapat dengan mudah dipanggil melalui API (Application Programming Interface) sistem operasi yang diatur dalam berbagai cara berorientasi objek berfungsi untuk memanfaatkan sepenuhnya sumber daya perangkat keras klien (misalnya, Anda dapat dengan mudah mengembangkan program multi-thread di atas .NET Framework untuk "memeras" kemampuan kerja CPU dual-core). Antarmuka pengguna semuanya dijelaskan menggunakan XAML, yang menyatukan teknologi lapisan antarmuka B/S dan C/S.
Lingkungan berjalan yang paling cocok untuk WPF adalah sistem operasi Vista. Sebuah subset dari fungsinya, sekarang disebut Silverlight, diimplementasikan sebagai plug-in browser, memungkinkan program WPF dijalankan di browser tradisional. Karena Silverlight dan Vista dapat mengurai XAML sendiri, Anda sekarang dapat menggunakan XAML untuk menulis hanya satu set kode antarmuka, yang berlaku untuk B/S dan C/S dan memperoleh pengalaman pengguna yang sama.
Karena beberapa kekurangan yang melekat pada B/S dan AJAX, jika sistem B/S yang ditingkatkan oleh AJAX dibandingkan dengan penari, maka sebenarnya itu adalah penari yang menari dengan belenggu, dan ide Microsoft adalah, Daripada terus-menerus berusaha mengurangi beban. dari belenggu ini, mengapa tidak meninggalkan belenggu ini saja?
Peluncuran WPF dan WCF oleh Microsoft adalah suatu upaya.
Harus dikatakan bahwa strategi pengembangan Microsoft didasarkan pada analisis kelebihan dan kekurangan B/S dan C/S yang ada, bersifat ilmiah dan juga mempertimbangkan kepentingan bisnisnya sendiri. Namun, masih banyak kesulitan dalam merealisasikan strategi ini, karena sekuat Microsoft sekalipun, ia tidak mampu mendominasi dunia. Lawan-lawan Microsoft sama pintarnya dengan Microsoft dan teknologi mereka juga maju dengan pesat.
Dapat disimpulkan bahwa karena kelangsungan penerapan sistem informasi, B/S dan C/S akan hidup berdampingan secara bersamaan untuk jangka waktu yang lama (mungkin tiga sampai lima tahun, mungkin lima sampai sepuluh tahun). banyak B/S Fitur unggulan yang luar biasa akan menang dalam persaingan dengan C/S, dan situasi ini tidak akan berubah secara signifikan. Adapun AJAX, sebagai senjata kelas berat dalam sistem B/S, meskipun sangat efektif, namun memiliki banyak kekurangan. Saya sangat optimis dengan perkembangannya di masa depan. Namun, sebagai pengembang Web, Anda harus memahami dan menerapkan teknologi ini.
Seperti apa lanskap masa depan, dan apakah suatu teknologi memiliki masa depan, tidak ditentukan oleh individu. Menurut saya, pola akhir pertarungan antara B/S dan C/S akan menjadi hasil permainan gabungan antara berbagai faktor. Bagi individu, mereka harus mengikuti perkembangan zaman dan menyesuaikan tindakan dan strategi mereka pada waktu yang tepat. Ini adalah nasib para pengembang perangkat lunak kontemporer.