Service Manager Di Zend Framework 2
Service Manager di Zend Framework 2 digunakan untuk menemukan dan mendapatkan instansi dari sebuah service (class), termasuk juga memenuhi segala dependensi yang dibutuhkan dari sebuah service.
Zend Framework 2 menggunakan Service Manager sebagai kerangka dari framework, dengan Service Manager khusus yang digunakan untuk menemukan service - service tertentu, seperti:
Service Locator design pattern menggambarkan sebuah method dari dari sebuah abstraction layer. Service Managers di Zend Framework 2, merupakan implementasi dari ServiceLocatorInterface interface yang memberikan dua method, yaitu has() untuk menentukan apakah sebuah service sudah didaftarkan di dalam Service Manager, dan get() untuk mengembalikan sebuah instansi dari service tersebut.
Banyak sekali implementasi dari ServiceLocatorInterface yang mempunyai tugas dengan letak yang berbeda dan plugin yang berbeda pula.
AbstractPluginManager adalah sebuah implementasi Service Manager untuk mengatur plugins. Abstract class memberikan method untuk mendefenisikan dan memanggil plugin, selama service tersebut dibuat melalui class invokable, factories, dan object yang dapat dipanggil seperti closure.
Zend\Mvc\Controller\ControllerManager meng-extend AbstractPluginManager, dan juga merupakan Plugin Manager yang mencari dan memanggil Controller class. Ini digunakan pada internal MVC Router untuk menentukan dan memanggil berdasarkan route url yang sesuai. ControllerManager ini memang sengaja dibuat terpisah untuk alasan kecepatan dan keamanan. Karena jika digabung bersama plugin manager yang lainnya, sangat mudah untuk melakukan dispatch terhadap controller dengan membuat route url untuk mengakses service tertentu yang sebenarnya tidak ditujukan untuk menjadi controller.
Ada beberapa kelompok Plugin Manager lainnya yang ditugaskan untuk membuat dan memanggil service dan plugin tertentu. Plugin - Plugin Manager tersebut juga meng-extend AbstractPluginManager.
ControllerPluginManager membuat dan memanggil controller plugin
ViewHelperPluginManager membuat dan memanggil view helper
InputFilterPluginManager membuat dan memanggil input filter
FilterPluginManager membuat dan memanggil filter
ValidatorPluginManager membuat dan memanggil validator
FormElementManager membuat dan memanggil form element
HydratorPluginManager membuat dan memanggil hydrator
Plugin - Plugin Manager ini akan menggunakan validatePlugin() untuk memastikan bahwa plugin - plugin yang terdapat dalam kelompok Plugin Manager tersebut sesuai dengan kriteria yang sudah ditentukan oleh Plugin Manager-nya.
Meskipun Plugin Manager sudah dikelompokkan, tidak tertutup kemungkinan juga bagi kita membutuhkan service lainnya yang berada di luar kelompok Plugin Manager tersebut. Maka dari itu dibuatlah Shared Service Manager. Zend\ServiceManager\ServiceManager adalah implementasi dari ServiceLocatorInterface yang digunakan untuk Custom Service. Yang biasanya digunakan unutk menyimpan Service yang dibuat oleh developer. Shared Service Manager ini bisa didapatkan dari getServiceLocator() yang ada pada AbstractPluginManager().
Perlu diingat, "Service Manager" yang dibahas di sini merujuk kepada Service Manager dan juga Plugin Manager
Service Manager dan Plugin Manager keduanya dapat dikonfigurasi dengan menggunakan Class yang merupakan implement dari Zend\ServiceManager\ConfigInterface sebagai parameter di constructor. Zend\ServiceManager\Config adalah salah satu bentuk implementasi yang sudah built-in dari Zend Framework 2, yang bisa digunakan untuk mengkonfigurasi Service Manager.
Sedangkan Zend\ServiceManager\Config menggunakan array sebagai constructor parameter. Dan menggunakan array tersebut untuk mengkonfigurasi Service Manager dengan factories, abstract factories, invokables, services, aliases dan initializers. Array tersebut dalam bentuk "key-value pairs", yang mana "key" adalah nama unik dari Service sebagai tanda pengenal Service, dan "value" akan mengembalikan sebuah Service.
Untuk diketahui, nama unik dari Service akan dinormalisasi. Spasi dan karakter - karakter khusus akan dihapus, dan karakter yang tersisa akan diubah ke "huruf kecil". Jadi "user-service" akan sama dengan "User\Service" yang akan dinormalisasi menjadi "userservice".
Invokables
Cara yang paling simple untuk membuat service melalui Service Manager adalah dengan menggunakan Invokable. Hanya berisi sebuah Class yang dapat menghasilkan object (instantiasi) tanpa menggunakan dependensi (ataupun dengan dependensi yang bisa dihandle oleh initializer). Untuk mendefenisikannya, gunakan "invokables" key pada array konfigurasi yang digunakan sebagai parameter Zend\ServiceManager\Config object
$config = new Config([
'invokables' => [
'hydrator' => 'Zend\Stdlib\Hydrator\ClassMethods'
]
]);
Maka untuk memanggil Service "hydrator" menggunakan Service Manager, bisa langsung seperti ini
$serviceManager = new ServiceManager($config);
$serviceManager->get('hydrator');
Factories
Factories merupakan sebuah Class ataupun Closure/Anonymous Function yang dapat mengembalikan sebuah object yang sudah dikonfigurasi pada saat Service tersebut dipanggil. Untuk penggunaan Class, harus meng-implement FactoryInterface. Kemudian Service dikonfigurasi di dalam method "createService()".
Closure dan Class keduanya akan menggunakan Service Manager object sebagai parameter. Ini ditujukan agar factory dapat memenuhi dependensi dari Service yang akan dikonfigurasi dengan memanggil dependensi tersebut dengan menggunakan Service Manager ataupun Shared Service Manager (menggunakan getServiceLocator())
Factories didefenisikan menggunakan "factories" key
$config = new Config([
'factories' => [
'mailTransport' => 'Aqilix\User\Factory\MailTransport',
'user' => function (ServiceLocatorInterface $serviceManager) {
$service = $serviceManager->get('UserService');
$user = new User($service); // $service digunakan sebagai dependency
return $user;
}
]
]);
Contoh Class yang digunakan sebagai factory
Ketika service diakses melalui Service Manager, maka service tersebut sudah berisi dependencies yang dibutuhkan.
$serviceManager = new ServiceManager($config);
$serviceManager->get('mailTransport');
Abstract Factories
Abstract Factories adalah factories yang dapat digunakan untuk membuat multiple services. Abstract Factories dibuat dengan sebuah Class yang meng-implement AbstractFactoryInterface. AbstractFactoryInterface mempunyai dua method yaitu canCreateServiceWithName() dan createServiceWithName().
Abstract Factories dipanggil setelah "factories" dan "invokables". Ketika sebuah service tidak ditemukan pada factories atau invokable, maka kemudian service manager akan mencek canCreateServiceWithName() method. Jika method tersebut mengembalikan true, maka service tersebut akan dipanggil melalui createServiceWithName() method. Berikut contoh sebuah class Abstract Factory
Kemudian Abstract Factory ini didefenisikan dengan menggunakan key "abstract_factories"
$config = new Config([
'abstract_factories' => [
'Aqilix\Common\Session\Service\AbstractContainerFactory'
]
]);
Class Abstract Factory di atas ditujukan untuk membuat Session Container baru yang bisa diakses melalui Service Manager. Untuk mengaksesnya dengan cara berikut ini:
$serviceManager = new ServiceManager($config);
$serviceManager->get('aqilix.common.session.container.user'); // Membuat Session Container User
Aliases
Aliases digunakan sebagai aliasing sebuah service yang sudah didefenisikan sebelumnya. Aliases didefenisikan dengan menggunakan key "aliases"
$config = new Config([
'aliases' => [
'user' => 'UserService'
]
]);
Memanggil user service melalui Service Manager
$serviceManager = new ServiceManager($config);
$serviceManager->get('user');
Initializers
Initializers digunakan untuk menjalankan inisialisasi tambahan setelah service dibuat. Service yang baru dibuat tersebut diberikan ke seluruh Initializers. Ini sangat berguna untuk menemukan dependensi menggunakan "setter injection". Initializers melakukan pengecekan dengan menggunakan "Aware" interface untuk memastikan bahwa service menemukan dependensi yang tepat.
Initializers didefenisikan menggunakan “initializers” key, dan memiliki value yang bisa berupa Closure ataupun "Class" yang meng-implement "InitializerInterface". Dan proses initialize tersebut ada pada method "initialize()". Berikut ini contoh Class yang digunakan sebagai initializer
Setter pada class berikut ini akan dipanggil oleh Initializer
interface UserServiceAwareInterface
{
public function setUserService(UserService $userService);
}
interface DbAdapterAwareInterface
{
public function setDbAdapter(DbAdapterInterface $dbAdapter);
}
Konfigurasi Initializer yang akan digunakan oleh Service Manager
$config = new Config([
'initializers' => [
'Aqilix\User\Initializer\Db',
'userService' => function ($service, ServiceLocatorInterface $serviceManager) {
if ($service instanceof UserServiceAwareInterface) {
$userService = $serviceManager->get('UserService);
$service->setUserService($userService);
}
}
]
]);
Dengan defenisi di atas, maka semua Service yang meng-implement UserServiceAwareInterface akan mempunyai UserService karena sudah diset melalui Initializers. Begitu juga dengan Service yang mengimplement DbAdapterAwareInterface
Shared Service
Shared Service berbeda dengan Shared Service Manager yang dibahas sebelumnya. Yang dimaksud dengan Shared Service di sini adalah tentang sebuah Service akan menggunakan object yang sama setiap kali dipanggil. Secara default, semua Service adalah shared.
Dalam artian Service Manager akan memberikan object yang sama dari sebuah Service ketika Service tersebut dipanggil melalui Service Manager. Namun adakalanya kita menginginkan sebuah Service, yang ketika dipanggil melalui Service Manager dia akan membuat object yang baru.
Untuk kebutuhan object seperti ini, maka harus didefnisikan di konfigurasi Service Manager dengan "shared" key.
'service_manager' => array(
'factories' => array(
'crypto' => 'Aqilix\User\Crypto\Service\Factory'
),
'shared' => array(
'crypto' => false,
),
);
Maka setiap kali Service crypto dipanggil, akan membuat object yang baru
$serviceManager = new ServiceManager($config);
$crypto = $serviceManager->get(’crypto’);
$newCrypto = $serviceManager->get(’crypto’);
assert($crypto !== $newCrypto, 'Each crypto object should not be same’);
Pada contoh - contoh di atas kita sudah menggunakan Class dan
Closure/Anonymous function untuk membuat sebuah Service. Tapi perlu diingat, penggunaan Closure hanya ditujukan untuk mempercepat development dan pengujian dari konsep sebuah aplikasi. Jangan pernah gunakan Closure untuk kode rilis, karena akan menimbulkan beberapa masalah di antaranya:
Cache konfigurasi akan rusak. Karena PHP tidak bisa men-serialize dan men-deserialize Closure. Oleh karena itu, jika ke depannya kita ingin melakukan cache untuk konfigurasi, maka cache ini tidak bisa bekerja.
Autoloading tidak akan bekerja seperti yang diharapkan. Kode yang ada pada Closure bisa jadi bergantung pada Class yang ada pada Modul berikutnya. Ini berarti Class tersebut belum diproses Autoloader, dan kode di Closure akan berhenti. Bahkan lebih buruk lagi, Autoloading dari Modul berikutnya bisa jadi meng-override autoloading dari Class di Modul sekarang. Sedangkan Aplikasi mengharapkan Class yang di-override, tapi yang terjadi yang diproses adalah Class sekarang yang belum di-override. Tentu saja ini akan memicu masalah baru yang akan sulit ditelusuri.
Ketika sebuah Service didefenisikan menggunakan Closure pada file konfigurasi, maka PHP akan memakan waktu untuk mengevaluasinya. Jika ada Modul lain yang meng-overwrite Service tersebut maka waktu yang sudah dihabiskan tersebut akan terbuang percuma. Oleh sebab itu, pikirkan kembali jika ingin menggunakan Closure.
Sampai saat ini, banyak source code Zend Framework 2 beredar di Internet yang menggunakan Closure.
Berikut ini contoh konfigurasi Service Manager pada aplikasi Zend Framework 2
Zend Framework 2 Learn By Example, Slavey Karadzhov
Zend Framework 2 Certification Sudy Guide
pixelskylines
2087
titsay
jbbartram-illu
vaporwave
