php - Apakah jenis seni bina yang boleh menghalang program daripada berjalan secara normal apabila struktur jadual berubah?
我想大声告诉你
我想大声告诉你 2017-06-21 10:10:45
0
10
821

Saya dididik oleh orang hadapan hari ini, mengatakan bahawa jika bahagian belakang mengubah sedikit struktur jadual (seperti memadam jadual atau menukar medan), program itu tidak akan berjalan untuk mengelakkan masalah di atas berlaku. Adakah saya perlu melakukan pemetaan medan untuk setiap jadual?

Sebagai tambahan, cerita yang berlaku di sini ialah jadual utama perpustakaan yang saya reka telah dipadamkan oleh lelaki lain, dan maksud beberapa medan yang perlu dinilai telah diubah medan status, yang serupa dengan menilai warna , telah ditukar kepada bentuk penghakiman, dan hasilnya ialah A front-end mengejek kod itu kerana tidak cukup mantap, mengatakan bahawa program mereka kehilangan sesuatu dan ia tidak mempunyai kesan (Android), yang membuatkan saya terdiam tahu bagaimana untuk menjelaskannya kepada dia, saya ingin tahu apa yang perlu dilakukan oleh Dalao dan orang lain tentang penyahgandingan berfungsi
我想大声告诉你
我想大声告诉你

membalas semua(10)
阿神

Saya rasa idea anda sangat bermasalah.
Program itu sendiri memproses data Perubahan dalam jadual data adalah bersamaan dengan perubahan dalam data dan struktur data itu sendiri. . Apatah lagi memadamkan jadual atau menukar medan, adalah perkara biasa untuk program mempunyai pepijat, melainkan data tersebut hanyalah kamus data, yang tidak akan memberi banyak kesan kepada logik itu sendiri.
Dan apa kejadahnya dididik oleh orang hadapan. Bahagian hadapan dan bahagian belakang hanya perlu melakukan kerja interaksi data yang baik Bahagian belakang menyediakan data, dan bahagian hadapan bertanggungjawab untuk memaparkannya Perubahan dalam struktur jadual tidak ada kaitan dengan front-end. Selagi antara muka data dan data yang disediakan oleh antara muka adalah normal, bahagian hadapan tidak akan tahu tentang apa yang berlaku pada hujungnya.

typecho

Reka bentuk pangkalan data mempertimbangkan paradigma pangkalan data dan tiga mod,
Tetapi tiada satu pun seni bina yang saya tahu boleh dipisahkan sepenuhnya Gandingan antara pangkalan data dan program hanya boleh dikurangkan melalui seni bina. Cara yang berkesan untuk menyelesaikan masalah ini ialah apabila mereka bentuk pangkalan data. Cuba memahami keperluan sebanyak mungkin, berfikir lebih lanjut, mengurangkan perubahan jadual, dan kemudian menyeragamkan kod dan menggunakan beberapa corak reka bentuk untuk meningkatkan kebolehskalaan.

学霸

Pangkalan data telah dipadamkan, bagaimana anda masih mengharapkan ia berjalan seperti biasa?
Saya rasa anda perlu mengendalikan pengecualian dengan baik Jika terdapat pengecualian dalam pangkalan data PDO, halaman itu boleh terus memaparkan [Pelayan sedang dimatikan] atau seumpamanya, dan antara muka boleh terus mengembalikan status = 500 atau seumpamanya. kesilapan sebenar bukanlah Setelah maklumat terdedah, itu sahaja.

Bagi bahagian hadapan atau Android yang saya beritahu anda, adakah apl yang saya tulis tidak pernah ranap?
Sentiasa ambil langkah demi langkah perlahan-lahan, anda tidak boleh menjadi gemuk dalam satu gigitan.

ringa_lee

Saya rasa menambah atau memadam medan akan menyebabkan program tidak dapat dijalankan Ini adalah masalah peribadi Sebelum program dalam talian, adalah perkara biasa untuk masalah pengubahsuaian struktur jadual kerana keperluan dan pengubahsuaian yang tidak jelas. lapisan model mestilah Pertanyaan perlu diubah suai Jika terdapat masalah, ia hanya boleh bermakna anda menulis program terlalu berantakan atau anda tidak menguji API untuk ditipu oleh bahagian hadapan cuma bahagian depan terus menyalahkan anda Masalah khusus masih perlu khusus

Tiada cara untuk memisahkannya sepenuhnya, tetapi ia boleh mengurangkan berlakunya perkara penipuan tersebut.
1. Pastikan anda melakukan kawalan versi Ini adalah satu kemestian. Malah, anda mengatakan bahawa orang lain telah memadamkan perubahan pada jadual utama ini perlu dibangunkan dan dilaksanakan dalam versi seterusnya. Jika ia boleh dilakukan oleh sesiapa sahaja, Jika anda menukar struktur jadual data, maka mesti ada sesuatu yang tidak kena dengan otak pengurus projek anda. Oleh itu, adalah perlu untuk menggunakan git, svn, dan lain-lain untuk kawalan versi
2 Lakukan kerja yang baik dalam kawalan kebenaran untuk mengelakkan masalah dalam proses penyebaran dari gudang ke dalam talian mesti. Terutama apabila ia berkaitan dengan perubahan pangkalan data, penambahan versi, pemadaman dan pengubahsuaian, ingatlah bahawa semakin sedikit orang yang mempunyai kebenaran, sistem akan menjadi lebih selamat.

phpcn_u1582

Tingkatkan logik program, tambah pengendalian pengecualian, perbaiki kod status mesej antara muka api, dan sediakan mekanisme pengendalian ralat untuk memastikan bahawa sebarang kemungkinan ralat atau pengecualian masih boleh mengeluarkan data ralat ke bahagian hadapan Hanya dengan cara ini cukup teguh Bagi lapisan pangkalan data, tidak perlu sama sekali.

我想大声告诉你

Anda tidak sepatutnya berfikiran begitu. Anda harus mempertimbangkan untuk menjalankan ujian asap untuk perlindungan API anda sebelum disiarkan secara langsung untuk mengelakkan ralat ini.

给我你的怀抱

Saya dapati bahawa balasan di atas semuanya "tuhan-tuhan yang hebat"! Kerana, dalam pemahaman saya yang terhad, saya fikir: memandangkan jadual data telah berubah, ini bermakna perniagaan dan kod mesti diselaraskan. Jika jadual data berubah dan kod tidak perlu diubah suai, maka saya ingin bertanya: Apakah gunanya mengubah suai jadual data? (Jangan pertimbangkan sama ada helaian data poster itu disebabkan oleh kesilapan orang lain). Tidak dapat dinafikan bahawa anda boleh menambah banyak pengecualian penangkapan pada program ini. Jadi, apa gunanya menangkap pengecualian sedemikian? Hanya untuk tidak mengembalikan ralat 500? Oleh itu, jika pangkalan data perlu diselaraskan, ia mesti disahkan bahawa kod juga mesti diselaraskan dengan sewajarnya Setelah mengesahkan bahawa tiada masalah, kedua-duanya akan dikemas kini pada masa yang sama.
Mari kita bercakap tentang bahagian hadapan, dia hanya bodoh yang banyak bercakap dan hanya tahu buta. Anda bertanya kepadanya: Jika definisi antara muka mengembalikan nama medan, dan suatu hari bahagian belakang menukarnya secara santai kepada tajuk, bolehkah bahagian hadapan mengecamnya secara automatik tanpa memberitahunya dan tidak melaporkan ralat?
Ringkasnya, jika terdapat sebarang perubahan pada bahagian hadapan, bahagian belakang, dan pangkalan data, ia mesti diuji melalui China Unicom terlebih dahulu Jika tiada masalah, ia akan diletakkan bersama-sama. Keadaan seperti poster asal hanya boleh dikatakan berpunca daripada tindakan manusia rakan sekerja 2B itu.

世界只因有你

Jadi tahap bahagian hadapan semakin rendah sekarang... Sudah tentu, rakan sekerja anda yang memadam pangkalan data adalah lebih kurang sama dengan bahagian hadapan ini

曾经蜡笔没有小新

Syarikat apa? Bolehkah jadual dipadam sesuka hati? Saya juga yakin, bahagian depan mengejek kod bahagian belakang kerana tidak cukup mantap? Bakat dalam syarikat anda benar-benar kacau.

習慣沉默

Pertama sekali, saya perlu mengatakan bahawa idea anda adalah salah dari titik permulaan.

  1. Pertama, saya harus mengakui bahawa selepas struktur jadual diubah, program masih boleh berjalan tanpa ralat, yang boleh dicapai. Dalam logik bahagian belakang, menambah pemprosesan toleransi kesalahan dan tangkapan ralat sebelum memproses data boleh menghalang maklumat ralat daripada dihantar terus ke bahagian hadapan dan menyebabkan bahagian hadapan ranap.

  2. Walau bagaimanapun, hanya kerana program tidak melaporkan ralat tidak bermakna fungsi tersebut bebas ralat. Izinkan saya mengambil situasi anda sebagai contoh Andaikan bahawa jadual utama anda ialah jadual pesanan asal tidak wujud Kerana pemprosesan toleransi kesalahan, tiada ralat akan dilaporkan, tetapi data tajuk pesanan tidak ditulis pangkalan data. Dalam kes ini, apabila menyahpepijat pengendali bahagian hadapan dan belakang, masalahnya mungkin tidak ditemui kerana program boleh berjalan seperti biasa. Kemudian apabila program ini diletakkan dalam talian untuk digunakan oleh pelanggan, dan pelanggan mendapati masalah ini, maka terdapat BUG sebenar. name,后来你把这个数据库字段改成了title,而没有改变后端的代码。由于后端有容错处理,所以下单还是可以正常下单的,但是由于原本标题写入name字段,现在name

  3. Mari kita ambil satu lagi contoh membuat pesanan. Anda mengatakan bahawa rakan sekerja anda telah memadamkan jadual utama (saya andaikan dia telah memadamkan jadual pesanan utama). Dalam kod anda, operasi pesanan ialah: tambah jadual utama dahulu, dan kemudian tambah data pada jadual lain jika jadual utama berjaya ditambahkan. Jika jadual utama gagal ditambah, ia akan melompat keluar secara langsung. Dalam kes ini, walaupun jadual utama dipadamkan, tiada ralat akan dilaporkan. Walau bagaimanapun, dengan cara ini, jika semasa ujian pasca pembangunan, bahagian hadapan, bahagian belakang dan operasi dan penyelenggaraan semuanya merasakan bahawa fungsi ini baik sebelum ini dan tidak perlu diuji semula, dan kemudian fungsi lain diuji dan diletakkan dalam talian, maka versi dalam talian boleh dihantar Pesanan, tetapi tiada data pesanan sebenarnya akan dijana (kerana jadual utama tidak ditulis dengan jayanya). Selepas BUG ini ditemui oleh pelanggan, ia dianggap sebagai kemalangan pengeluaran.

  4. Jadi, saya secara peribadi percaya bahawa adalah perlu untuk melakukan toleransi kesalahan kod dan penangkapan ralat pada bahagian belakang, tetapi ini tidak bermakna hanya kerana program bahagian hadapan tidak mempunyai masalah yang dapat dilihat dengan mata kasar, kita hanya boleh menukar pangkalan data tanpa mengubah logik yang berkaitan. Selepas mengubah suai pangkalan data dan membetulkan logik bahagian hadapan dan bahagian belakang, keseluruhan fungsi bebas perlu diuji semula untuk memastikan ia betul sebelum ia boleh pergi ke dalam talian.

Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan
Tentang kita Penafian Sitemap
Laman web PHP Cina:Latihan PHP dalam talian kebajikan awam,Bantu pelajar PHP berkembang dengan cepat!