Banyaknya bundel yang merupakan bagian dari kerangka Symfony2 dan bundel pihak ketiga yang tersedia merupakan lapisan integrasi yang efektif antara perpustakaan dan kerangka kerja. Misalnya:
Jadi apa yang ada di dalam bundel itu? Hal yang umum dilakukan adalah mengintegrasikan definisi layanan ke dalam aplikasi Symfony2 daripada membuat objek secara manual. Selain itu, konfigurasi objek ini diekspos melalui ekstensi injeksi ketergantungan, yang memungkinkan konfigurasi dari keseluruhan file konfigurasi aplikasi.
Dalam banyak kasus, perpustakaan ditulis menggunakan injeksi ketergantungan, tetapi definisi yang menghubungkannya adalah bagian dari paket. Dalam beberapa kasus, perpustakaan tidak ditulis menggunakan injeksi ketergantungan, namun bundel masih dapat berisi definisi layanan untuk mengintegrasikannya ke dalam aplikasi Symfony.
Definisi layanan bukan satu-satunya cara untuk mengintegrasikan perpustakaan ke dalam bundel, ada juga ekstensi cabang, templat cabang, dan beberapa juga memiliki pengontrol, pendengar acara, dll.
Dalam beberapa kasus, seperti halnya frame itu sendiri, frame dapat dibagi lagi menjadi jembatan dan bundel. Misalnya, ekstensi ranting dan pendengar doktrin tidak spesifik untuk Symfony2 dan dapat ada di jembatan bersama dengan definisi layanan pemrosesan yang dibundel, dengan tag untuk mendaftarkannya secara otomatis ke aplikasi. Ini akan memungkinkan aplikasi non-Symfony2 lainnya tetapi menggunakan Doctrine atau Twig untuk menggunakan templat dan pendengar.
Teknik ini juga bekerja dengan baik untuk kode dalam suatu aplikasi, di mana alih-alih memiliki semuanya dalam satu paket, kode khusus non-kerangka kerja dipecah menjadi perpustakaan dan disatukan kembali menggunakan paket terkait. Menggunakan kode khusus kerangka kerja membuka kemungkinan untuk menggunakan kembali perpustakaan di aplikasi lain yang tidak memiliki kerangka kerja atau kerangka kerja lainnya. Meskipun tidak berfungsi di aplikasi lain, ini akan membantu migrasi aplikasi ini di masa mendatang. Dengan cara ini, bundel bergantung pada aplikasinya, tetapi tidak sebaliknya, sehingga lebih mudah untuk dipindahkan.
Ini tidak berarti bahwa tidak ada kode Symfony yang boleh digunakan di perpustakaan, masih masuk akal untuk menggunakan komponen-komponen ini, tetapi masuk akal untuk menghindari kode dari bundel dan jembatan, karena Anda hanya memperkenalkan ketergantungan pada komponen yang Anda gunakan hubungan, bukan kerangka ketergantungan pada seluruh komponen. Tentu saja, ini dapat ditentukan dalam file composer.json bundel sehingga dapat dengan mudah diinstal secara independen di tempat lain.
Kasus yang paling jelas adalah kode yang diekstraksi dari bundel ke perpustakaan adalah kode infrastruktur, seperti halnya dengan sebagian besar kombinasi bundel/perpustakaan pihak ketiga. Misalnya, jika persyaratan logging spesifik aplikasi Anda tidak dapat dipenuhi oleh solusi yang ada, seperti harus berinteraksi dengan server agregasi log internal. Dengan menyimpan segala sesuatu yang terkait dengan ini di pustaka dan bundel terpisah, ini dapat digunakan di aplikasi lain dan mempermudah migrasi di masa mendatang. Hal ini juga memudahkan untuk menghindari kode ini menjadi bergantung pada persyaratan khusus aplikasi atau memperburuk logika bisnis, yang seharusnya tidak terjadi pada kode infrastruktur ini.
Bagaimana dengan logika bisnis khusus aplikasi? Apakah ada manfaatnya melakukan hal ini? Sepertinya ini tidak akan berguna di luar aplikasi ini, namun jika ini adalah bagian dari bisnis maka kemungkinan besar akan berguna di aplikasi lain, meskipun tidak langsung terlihat. Bahkan jika itu tidak digunakan dalam aplikasi yang berbeda, jika logika bisnis tidak memiliki ketergantungan kerangka kerja, maka setiap migrasi di masa depan, bahkan hanya ke versi utama Symfony yang baru daripada kerangka kerja yang berbeda, akan jauh lebih mudah.
Manfaat lainnya adalah pemisahan paksa antara logika khusus aplikasi dan logika bisnis. Meskipun kita tidak pernah bermaksud atau menggunakan logika bisnis di luar aplikasi ini, menjadikannya berfungsi di luar aplikasi akan membantu kita membuat logika bisnis yang dipisahkan dari aplikasi dan mempermudah pemeliharaan dan perluasannya. Pada akhirnya, kami tidak akan lagi membuat keputusan logika bisnis berdasarkan kebutuhan kerangka kerja tersebut.
Tidak seperti kode infrastruktur yang relatif mudah untuk memisahkan hal-hal spesifik non-kerangka tetapi dalam logika bisnis akan menjadi lebih sulit jika kita memindahkan entitas, repositori, dll dari paket bundel, bagaimana kita menggunakan formulir dan validasi, dll? Ini adalah sesuatu yang akan saya bahas dalam beberapa artikel berikutnya.
