Keskustelu: Nettisivujen teko: ZF2 ja SOAP-palvelimen oikeaoppinen toteutus

Heps, olemme alkaneet viime aikoina kehittää lähes poikkeuksetta ZF2 päälle. Nyt olisi tarvetta luoda hieman monipuolisempi SOAP palvelu yhdelle sovellusprojektille. Alustavasti ajattelin luoda palvelun projektin kylkeen omana ZF2 moduulina, mutta nyt kun rupesin suunnitelmia raapustamaan aloin hieman pohtimaan että kuinka paljon saa ja kannattaa hyödyntää aikaisemmin toteutettuja malleja yli moduulin rajojen? Saan toki nätisti käärittyä SOAP/WSDL palvelimen luokat ym. kikkurat omaan moduuliin, mutta rikonko Zend hirviön lakeja jos hyödynnän yksinkertaisesti naapuri moduulin valmiit tietolähteet.?

Miten tätä kannattaisi oikeaoppisesti lähestyä?

Tietysti moduuleilla saa olla riippuvuuksia toisiin moduuleihin.

Siitähän ei ollut kysymys. Senhän voisi olisi aika haastavaa rakentaa järjestelmä ilman niitä. Tiedustelin lähinnä että poikkeaako SOAP palvelun toteutus tästä ja onko jotain parempaa lähestymistapaa. Esimerkiksi tarvittavan model - kerroksen integrointi uuteen SOAP moduliin, josta taas muut moduulit käsittelisivät siltä osin SOAP palvelun avulla ko. tietoa.

Ongelma on siinä kun järjestelmä oli jo "valmis", ja SOAP palvelu keksittiin lisätä myöhemmin. Tähän kaipaisin hyviä neuvoja, jos on jotain mitä pitää huomioida, ettei tee turhia riippuvuuksia ja/tai turhaa työtä.

Ehkä pääset helpolla niin, että lisäät moduuliisi SOAP-serverin tarvitseman luokan (minne injektoit jo olemassa olevat modulin tarpeelliset matskut) ja mikä tarjoaa vain SOAP-serverille tarpeelliset toiminnot. Sitten konfiguroit SOAP-serverin sopivasti käyttämään tätä luokkaa.

Kiios, avusta. Luon tällä WSDL määrittelyt php2wsdl kikkareella. Onko sinulla ehdottaa parempaa työkalua?

Ps. soapUI on kyllä ehdoton apuohjelma kun testaa sovelluspalveluita.

Varmaankin Zendin mukana tuleva http://framework.zend.com/manual/2.2/en/modules/zend.soap.auto-discovery.html hoitaa homman. Muistaakseni se pelasi mallikkaasti.

Ok, täytyy todella tutustua Zendin omiin SOAP toiminnallisuuksiin ennen kun tekee mitään omaa kovin pitkälle.

Mitä sääntöjä kannattaa noudattaa kun luo modulien service konfuguraation. Miten pitkälle kannattaa määritellä?
Minulla on ollut tähän asti peukalosääntönä se että palvelun ulkopuoliset riippuvuudet täydennetään, ja palautetaan käyttövalmis instanssi.

Otetaan esimerkkinä rekisteröintilomake.

//Module.php

	'RegisterForm' => function($sm) {

         $form = new Register\Form();
         $form->setInputFilter($sm->get('RegisterFormInputFilter'));
         $form->setHydrator($sm->get('UserHydrator'));
         $form->bind($sm->get('UserEntity'));
         return $form;
     },

//UserService.php

	public function register(array $data) {

		$form = $this->getRegisterForm();
		$form->setData($data);

		if(!$form->isValid())
			return false;

		$entity = $form->getData();
		$entity->setPassword($this->getCrypt()->create($entity->getPassword()));

		return $this->getUserMapper()->insert($entity);
	}

vs.

//Module.php

	'RegisterForm' => function($sm) {

         $form = new Register\Form();
		 $form->setInputFilter($sm->get('RegisterFormInputFilter'));
         return $form;
     },

//UserService.php

	public function register(array $data) {

		$form = $this->getRegisterForm();
        $form->setHydrator(new UserHydrator());
        $form->bind(new UserEntity());
		$form->setData($data);

		if(!$form->isValid())
			return false;

		$entity = $form->getData();
		$entity->setPassword($this->getCrypt()->create($entity->getPassword()));

		return $this->getUserMapper()->insert($entity);
	}

Toisessa vaihtoehdossa jätetään hydraattorin määrittely ja entityyn bindaus varsinaisen UserService::register:in tehtäväksi. Toki RegisterForm - luokkaa on täysin käyttökelpoinen myös ilman niitä, mutta tuskin koskaan tulisi käytettyä niin. Mutta joku muu factoria hyödyntävä ei voi tietää mitä RegisterForm pitää sisällään.. Kuulostaa varmaan aika triviaalilta, mutta mikä olisi hyvä sääntö isossa mittakaavassa.?

(Koittakaa saada minun suomenkielestä jotain selvää..)

timoh?

En ZF2:ta näiltä osin tunne, mutta perstuntumalta luulen että myös ZF:n kanssa kannattaa module konfiguroida oletuksena niin kuin sitä useimmiten käytetään (miten se module sitten ikinä konfiguroidaankaan), ja sitten luoda setterit millä voit muuttaa oletuskonfiguraatiota.

Eli käytännössä et kutsu koodissa suoraan new UserHydrator() tai new UserEntity(), vaan törkkäät ne (konfiguraatiossa määritellysti) constructorissa sisään (tai jos ei ole kyseessä vaadittu riippuvuus niin setterissä).