Pengenalan kepada Proksi Maya, Bahagian 2

Points Core

• proksi maya berdasarkan polimorfisme membolehkan pembinaan/pemuatan graf objek mahal tanpa mengubah kod klien. Ejen
• boleh direka untuk bekerja dengan objek tunggal atau pengumpulan objek, memberikan fleksibiliti dan kecekapan dalam menguruskan data. Ejen maya
• sangat berkesan dalam koleksi pemuatan malas objek domain dalam penyimpanan (mis., Satu kumpulan catatan blog di mana komen yang relevan dapat diekstrak dari pangkalan data atas permintaan).
• Proksi yang mensimulasikan tingkah laku koleksi komen sebenar direalisasikan melalui pemetaan data, dengan itu meningkatkan ketekunan kegigihan.
• Proksi maya adalah alat yang berkesan untuk melambatkan pelaksanaan tugas-tugas yang mahal (mis. Menunda memuatkan sejumlah besar data dalam peringkat penyimpanan) dan mengurangkan masalah ketegaran dan kelemahan yang sama dalam aplikasi berorientasikan objek. Nama agen maya terdengar mewah, tetapi mungkin salah satu contoh yang paling menonjol dari konsep "pengaturcaraan berorientasikan antara muka" yang lebih daripada sekadar prinsip dogmatik yang membosankan. Proksi maya didasarkan pada polimorfisme (polimorfisme dinamik, bukannya polimorfisme sementara yang dilaksanakan melalui kaedah mudah), dan merupakan konsep yang mudah dan boleh dipercayai yang membolehkan anda melambatkan bangunan/memuat graf objek mahal tanpa mengubah kod klien. Kelebihan besar ejen adalah bahawa mereka boleh direka secara konseptual untuk bekerja dengan objek tunggal atau pengumpulan objek (atau kedua -duanya, walaupun berbuat demikian boleh menjejaskan pemisahan kebimbangan dan sukar untuk dikendalikan dari masa ke masa). Untuk menunjukkan dari perspektif praktikal bagaimana untuk memanfaatkan fungsi yang disediakan oleh proksi maya, di bahagian pertama siri ini, saya memperkenalkan beberapa contoh proses pembangunan yang menunjukkan cara mengekstrak agregat dari pangkalan data menggunakan proksi asas untuk memenuhi model domain yang mudah. Walaupun pengalaman itu dapat bermanfaat dan, bernasib baik, ia juga menyeronokkan, sisi lainnya agak menipu kerana ia menunjukkan selok -belok ejen maya, tetapi tidak menunjukkan cara melaksanakannya dalam senario yang lebih realistik. Proksi ini tidak dapat ditandingi dari segi pengumpulan objek domain dalam penyimpanan pemuatan malas. Untuk memahami konsep ini, pertimbangkan satu kumpulan catatan blog, di mana setiap set komen yang berkaitan boleh diekstrak dari pangkalan data atas permintaan;

Biasanya, amalan adalah guru terbaik. Dalam bahagian ini, saya akan menunjukkan cara menyambungkan proksi ke koleksi objek khusus domain. Saya akan menghasilkan semula senario tipikal ini pada tahap yang sangat asas supaya anda dapat dengan mudah memahami logik memandu.

Buat koleksi objek Realm

Seperti yang dinyatakan sebelum ini, ejen maya biasanya dibuat apabila mendapat akar agregat yang terikat pada pengumpulan objek Realm yang mendasari dari lapisan ketekunan. Oleh kerana sifat koleksi, dalam banyak kes, pra-penetapan koleksi adalah mahal, menjadikan mereka calon yang baik untuk memuatkan permintaan untuk mengurangkan pangkalan data pusingan di atas kepala. Selain itu, memandangkan hubungan "satu-ke-banyak" antara jawatan blog dan komen yang sepadannya agak setia dalam kes penggunaan ini, ia akan menjadi instruktif untuk memodelkan hubungan pertama melalui beberapa kelas domain yang mudah sebelum berurusan dengan ejen tertentu. Untuk membuat perkara lebih mudah difahami, kedua -dua peserta yang saya akan tambah semasa fasa ujian akan menjadi antara muka terpencil dan pelaksana asas. Kedua -dua ini bergabung untuk menentukan kontrak dan pelaksanaan objek pos blog generik:

<?php namespace Model;
use ModelCollectionCommentCollectionInterface;

interface PostInterface
{
    public function setId($id);
    public function getId();

    public function setTitle($title);
    public function getTitle();

    public function setContent($content);
    public function getContent();

    public function setComments(CommentCollectionInterface $comments);
    public function getComments();
}

<?php namespace Model;
    use ModelCollectionCommentCollectionInterface;

class Post implements PostInterface
{
    protected $id;
    protected $title;
    protected $content;
    protected $comments;

    public function __construct($title, $content, CommentCollectionInterface $comments = null)  {
        $this->setTitle($title);
        $this->setContent($content);
        $this->comments = $comments;
    }

    // ... (Post class methods remain largely unchanged) ...
}

Memahami logik kelas pasca di atas adalah proses yang mudah dan tidak memerlukan penjelasan yang nyata. Walau bagaimanapun, di sini adalah perincian yang berkaitan dengan yang perlu diberi perhatian: Kelas secara eksplisit mengisytiharkan kebergantungan pada koleksi komen yang belum ditakrifkan dalam pembina. Sekarang mari kita buat kelas yang menghasilkan komen pos:

<?php namespace Model;

interface CommentInterface
{
     public function setId($id);
     public function getId();

     public function setContent($content);
     public function getContent();

     public function setPoster($poster);
     public function getPoster();
}

<?php namespace Model;

class Comment implements CommentInterface
{
    protected $id;
    protected $content;
    protected $poster;

    public function __construct($content, $poster) {
        $this->setContent($content);
        $this->setPoster($poster);
    }

    // ... (Comment class methods remain largely unchanged) ...
}

Setakat ini, semuanya telah berjalan lancar. Selain daripada blok nipis model domain asas, tidak ada yang boleh dikatakan mengenai kelas domain di atas, di mana setiap objek pos blog membuka persatuan "satu-ke-banyak" dengan komen yang berkaitan. Anda boleh memanggil saya seorang pemurni jika anda mahu, tetapi seolah -olah saya bahawa jika pelaksanaan model semasa tidak dipertingkatkan dengan koleksi komen, ia kelihatan tidak lengkap dan canggung. Mari buat model lebih kaya dengan menambahkan komponen tambahan ini:

<?php namespace ModelCollection;

interface CommentCollectionInterface extends Countable, IteratorAggregate
{
    public function getComments();
}

<?php namespace ModelCollection;
use ModelCommentInterface;

class CommentCollection implements CommentCollectionInterface
{
    protected $comments = array();

    public function __construct(array $comments = array()) {
        // ... (CommentCollection class methods remain largely unchanged) ...
    }
}

Jika anda melihat dengan teliti dan melayari kelas CommentCollection, anda akan terlebih dahulu menyedari bahawa ia tidak lebih daripada pembungkus array yang boleh diselaraskan di belakang penyamaran cantik. Malah, koleksi array datang dalam pelbagai bentuk dan gaya, tetapi kebanyakan masa mereka hanya penggunaan mudah dari kelas Iterator dan Arrayaccess SPL. Dalam kes ini, saya ingin menyelamatkan diri saya (dan anda) dari tugas yang membosankan dan menjadikan kelas pelaksana iteratoraggregate. Dengan koleksi komen, kita boleh melangkah lebih jauh dan membiarkan model domain melakukan apa yang perlu dilakukan -bekerjasama dengan beberapa objek pos blog, atau bahkan menghubungkannya dengan satu kumpulan komen dengan penuh semangat diambil dari pangkalan data. Tetapi berbuat demikian hanya akan menipu diri kita tanpa memanfaatkan sepenuhnya keupayaan yang disediakan oleh proksi maya. Memandangkan dalam pelaksanaan tipikal, proksi mendedahkan API yang sama sebagai objek domain sebenar, proksi yang berinteraksi dengan kelas CommentCollection sebelumnya juga harus melaksanakan CommentCollectionInterface untuk mematuhi kontrak dengan kod klien tanpa memperkenalkan sekumpulan pernyataan bersyarat yang bermasalah.

Interaksi dengan koleksi objek domain melalui ejen maya

Secara terang -terangan bercakap, koleksi tatasusunan pembalut, seperti yang disebutkan sebelumnya, boleh wujud secara bebas tanpa bergantung kepada sebarang kebergantungan lain. . Persoalan yang perlu ditanya ialah: Bagaimana anda mengekstrak komen dari pangkalan data dan memasukkannya ke dalam koleksi sebelumnya? Terdapat beberapa cara untuk mencapai matlamat ini, tetapi saya fikir yang paling menarik adalah melalui pemetaan data kerana ia meningkatkan ketidakpatuhan kegigihan. Mapper di bawah menjadikannya bagus untuk mendapatkan koleksi komen dari penyimpanan. Sila periksa:

<?php namespace Model;
use ModelCollectionCommentCollectionInterface;

interface PostInterface
{
    public function setId($id);
    public function getId();

    public function setTitle($title);
    public function getTitle();

    public function setContent($content);
    public function getContent();

    public function setComments(CommentCollectionInterface $comments);
    public function getComments();
}

<?php namespace Model;
    use ModelCollectionCommentCollectionInterface;

class Post implements PostInterface
{
    protected $id;
    protected $title;
    protected $content;
    protected $comments;

    public function __construct($title, $content, CommentCollectionInterface $comments = null)  {
        $this->setTitle($title);
        $this->setContent($content);
        $this->comments = $comments;
    }

    // ... (Post class methods remain largely unchanged) ...
}

Walaupun pencari yang terdedah oleh kelas CommentMapper biasanya berpegang pada API yang mungkin dijangka dalam pelaksanaan pemetaan data standard, kaedah Fetchall () adalah kaedah yang paling menarik. Ia mula -mula mengekstrak semua komen blog pos dari storan dan meletakkannya ke dalam koleksi, dan akhirnya mengembalikan koleksi ke kod klien. Sekiranya anda seperti saya, anda mungkin mempunyai panggilan bangun dalam fikiran anda kerana koleksi itu ditimbulkan secara langsung di dalam kaedah. Malah, tidak perlu panik mengenai pengendali baru yang menyelinap di luar kilang, sekurang -kurangnya dalam kes ini, kerana koleksi itu sebenarnya merupakan struktur umum yang berada di bawah kategori "dicipta", bukannya kategori "suntikan". Bagaimanapun, jangan ragu untuk melakukannya jika anda merasa sedikit kurang bersalah dengan menyuntik koleksi ke dalam pembina pemetaan. Dengan Mapper Komen, sudah tiba masanya untuk mengalami epiphany sebenar dan membina kelas proksi yang mengantara dengan set sebelumnya:

<?php namespace Model;

interface CommentInterface
{
     public function setId($id);
     public function getId();

     public function setContent($content);
     public function getContent();

     public function setPoster($poster);
     public function getPoster();
}

Seperti yang anda harapkan, CommentCollectionProxy melaksanakan antara muka yang sama sebagai koleksi komen sebenar. Walau bagaimanapun, kaedah GetComments () melakukan kerja sebenar di belakang tabir dan menangguhkan pemuatan komen dari pangkalan data melalui mapper yang diluluskan dalam pembina. Kaedah yang mudah dan berkesan ini membolehkan anda melakukan semua jenis tindakan pintar pada komen anda tanpa terlalu banyak kerja. Adakah anda ingin melihat kaedah apa yang anda mahu lihat? Katakan anda perlu mendapatkan semua komen yang terikat pada catatan blog tertentu dari pangkalan data. Coretan kod berikut boleh melakukan ini:

<?php namespace Model;

class Comment implements CommentInterface
{
    protected $id;
    protected $content;
    protected $poster;

    public function __construct($content, $poster) {
        $this->setContent($content);
        $this->setPoster($poster);
    }

    // ... (Comment class methods remain largely unchanged) ...
}

Kelemahan pendekatan ini adalah bahawa komen pertama diekstrak dari storan dan kemudian disuntik ke dalam objek pos. Bagaimana untuk melakukannya dengan cara yang lain, tetapi kali ini ia adalah "spoof" kod klien dengan proksi?

<?php namespace ModelCollection;

interface CommentCollectionInterface extends Countable, IteratorAggregate
{
    public function getComments();
}

Komen bukan sahaja melambatkan pemuatan secara telus dari pangkalan data selepas proksi diletakkan di dalam gelung foreach, tetapi API yang terdedah kepada kod klien menyimpan struktur asalnya tidak berubah sepanjang proses. Adakah kita berani meminta sesuatu yang lebih baik? Kecuali anda sangat tamak, sukar bagi saya untuk berfikir demikian. Dalam kedua -dua kes, anda harus memahami realiti di sebalik tabir ejen maya dan bagaimana untuk memanfaatkan kemampuannya dalam meningkatkan kecekapan operasi objek domain dan lapisan kegigihan yang mendasari.

Kesimpulan

Walaupun mudah, terutamanya jika anda cukup berani untuk menggunakannya dalam persekitaran pengeluaran, contoh sebelumnya secara ringkas menunjukkan beberapa konsep yang menarik. Pertama, ejen maya bukan sahaja mudah untuk ditubuhkan dan digunakan, tetapi tidak dapat ditandingi dalam mencampurkan pelaksanaan yang berbeza pada masa runtime untuk menangguhkan melakukan tugas yang mahal (mis., Menangguhkan memuatkan sejumlah besar data dalam peringkat penyimpanan atau membuat graf objek kelas berat). Kedua, mereka adalah contoh klasik bagaimana polimorfisme dapat menjadi vaksin yang berkesan yang mengurangkan masalah ketegaran dan kelemahan yang banyak yang banyak aplikasi berorientasikan objek. Selain itu, kerana model objek PHP adalah mudah dan menyokong penutupan, adalah mungkin untuk mencampurkan ciri -ciri ini dengan bijak dan membina proksi yang logik asasnya didorong oleh kelebihan penutupan. Jika anda ingin menangani cabaran ini sendiri, saya berharap anda semua yang terbaik terlebih dahulu.

(gambar dari imredesiuk / shutterstock)

Atas ialah kandungan terperinci Pengenalan kepada Proksi Maya, Bahagian 2. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!