Armetiz

Le pattern Transfert Object TO, Data Transfert Object DTO, ou encore Value Object VO permet d’échanger des données entre deux applications.

Wikipédia : Son but est de simplifier les transferts de données entre les sous-systèmes d’une application logiciel. Les objets de transfert de données sont souvent utilisés en conjonction des objets d’accès aux données.

Qui dit Transfert Object, veux aussi dire Transfert Object Assembler.

Conversion d’object

Le pattern Transfert Object Assembler permet de passer d’un DTO à un Objet d’accès au données, et inversement.
C’est le moyen le plus simple pour travailler avec le pattern Data Transert Object et un ORM.

Domain Object Model -> Data Transfert Object

Avec l’ORM Doctrine, le transfert d’un « Domain Object Model DOM » ou ici Doctrine_Record vers un DTO est très simple.
Il suffit de réaliser un parser qui analyse l’objet issu de Doctrine, et qui remplit les données du DTO.

Data Transfert Object -> Domain Object Model

Convertir un DTO vers un DOM peut s’avère plus complexe.
En effet, Doctrine utilise des collections d’objet qui lui sont propres, mais a aussi besoin de connaitre les clés primaires et leurs contenus pour pouvoir créer un objet. Car un objet issu de Doctrine_Record n’a pas les même propriétés quand il est existant en base de donnée, ou qu’il est en phase d’être sauvegardé.

Implémentation de Transfer Object Assembler

Une implémentation du pattern Transfert Object Assembler vient de voir le jour après moult et moult péripéties.

Cette implémentation permet donc le transférer de DTOs à partir de DOMs et inversement.
Associer au pattern Service Layer, cela peut s’avérer être très pratique.

Voici un exemple simple d’utilisation :

$oProgram = new ProgramDTO ();
$oProgram->title = "Dorothe";
 
$oVideoDTO = new VideoDTO ();
$oVideoDTO->idVideo = 30;
$oVideoDTO->program = $oProgram;
 
$oAssembler = $new Assembler ();
$oVideo = $oAssembler->createDomainObject ($oVideoDTO);
$oVideo->save ();

Nous avons ici créé une nouvelle entrée dans la table programs, et réalisé une liaison entre ce nouvel objet et la vidéo existante d’identifiant 30.
Le tout one-shot !

L’intérêt de cette implémentation, c’est d’être fonctionnel avec :

• Les objets persistant
• Les objets non-persistant
• Les compositions d’objets sur N niveau

Utilisation avec le pattern Service Layer

Nous allons voir l’exemple le plus simple, soit l’implémentation des méthodes CRUD pour un objet générique.
L’utilisation du nommage des classes provient de l’utilisation de Zend Framework.

/**
 * @param Model_DTO_Video
 * @return Model_DTO_Video
 */
public function create (Model_DTO_Video $poVideoDTO)
{
	$oModelVideo		= null;
	$oAssembler		= new Model_Utils_Assembler ();
	$oModelVideo		= $oAssembler->createDomainObject($poVideoDTO, true);
	$oModelVideo->save ();
	$poVideoDTO->idShow	= $oModelVideo->idShow;
	return $poVideoDTO;
}
 
/**
 * @param Model_DTO_Video
 * @return Model_DTO_Video
 */
public function read (Model_DTO_Video $poVideoDTO)
{
	$query	= Doctrine_Query::create ()
		->select ("video.*")
		->from ("Model_Video video")
		->where ("video.id_show = ?", $piIdVideo);
	$oModelVideo	= $query->fetchOne ();
	$oAssembler	= new Model_Utils_Assembler ();
	return $oAssembler->createTransfertObject ($oModelVideo);
}
 
/**
 * @param Model_DTO_Video
 * @return Model_DTO_Video
 */
public function update (Model_DTO_Video $poVideoDTO)
{
	$oModelVideo	= null;
	$oAssembler	= new Model_Utils_Assembler ();
	$oModelVideo	= $oAssembler->createDomainObject($poVideoDTO, true);
	$oModelVideo->save ();
 
	return $poVideoDTO;
}
 
/**
 * @param Model_DTO_Video
 * @return Model_DTO_Video
 */
public function delete (Model_DTO_Video $poVideoDTO)
{
	$oModelVideo	= null;
	$oAssembler	= new Model_Utils_Assembler ();
	$oModelVideo	= $oAssembler->createDomainObject($poVideoDTO, false);
	$oModelVideo->delete ();
 
	return $poVideoDTO;
}

Téléchargement

Contenu de l’archive :

• Implémentation du pattern Transfer Object Assembler
• Interface du pattern Transfer Object Assembler
• Classe de définition d’un DTO

Pour faire fonctionner l’assembler. Vous devez définir une classe qui hérite de Assembler, et ainsi surchargez la propriété $_relationships avec vos liaisons entre DTO et DOM.

Dernière mise à jour : 22 Juillet 2010
Transfert_Object_Assembler_Doctrine_1.1.zip – 3 Ko.

Suite au commentaire de webstorming sur l’article : Flash – Restreindre l’instanciation d’une classe par un seul objet.

Voici l’implémentation du pattern singleton en Flash.

public class PatternSingleton
{
	private static var _instance : Object;
 
	public function PatternSingleton () : void
	{
		if (_instance)
			throw new Error ("Pattern Singleton : only one instance is permit");
		_instance = this;
	}
 
	public function sayHello () : String
	{
		return "Hello World";
	}
 
	public static function get instance () : PatternSingleton
	{
		if (!_instance)
			new PatternSingleton ();
		return PatternSingleton (_instance);
	}
}

Nous avons donc une class ne pouvant être instanciée qu’une seule fois, et accessible de n’importe où au sein de notre application.

trace (PatternSingleton.instance.sayHello ());

Wikipédia

L’implémentation que l’on trouve sur Wikipédia est différente de celle ci-dessus.
En effet, elle utilise la définition d’une constante globale sans modification du constructeur.
Le problème induit, c’est que l’instanciation multiple n’est pas interdite au sein de l’application. Et la compréhension par un débutant est moins aisée.

Comment restreindre l’instanciation d’une classe à une autre classe.

Voici une idée complètement « crazy » au quelle je vais apporter une solution à travers ce billet.
Nous allons utiliser un principe connu par de nombreux framework Web qui permet d’assurer la validité d’un formulaire: Le jeton !

L’intérêt étant de combiner cela avec le pattern Factory.

public class Master
{
	private static var _jeton	: Number	= -1;
 
	public function Master()
	{
	}
 
	public static function createSlave () : Slave
	{
		var _tmpSlave	: Slave;
 
		_jeton		= Math.random() * 500;
		_tmpSlave	= new Slave (_jeton);
		_jeton		= -1;
 
		return _tmpSlave;			
	}
 
	public static function get jeton () : Number
	{
		return _jeton;
	}
}

public class Slave
{
	public function Slave(_pJeton : Number = 0) : void
	{
		if (Master.jeton !== _pJeton && Master.jeton !== -1)
			throw new Error ("Instanciation obligatoire par Master.createSlave");
	}
}

new Slave (); //throw Error
Master.createSlave (); //Retourne un objet du type Slave

Fabien de la Fabrick a publié une « micro-architecture » MVC pour Flex.
Ces mots de présentation sont :

Souvent dans le monde de Flex, les équipes ne sont pas forcement homogènes. Certains sont habitués à la rigueur de Java, d’autres sont plus “devsigners freestyle” venant du monde Flash. Les premiers aiment les grosses mécaniques comme PureMVC, ou Prana Framework “Spring like”. Les seconds connaissent au mieux Cairngorm, au pire confondent MVC et VMC – ce qui n’a rien a voir, sauf si vous faites une application riche sur le thème de la ventilation.

Pour l’instant deux didacticiels sont disponibles : Introduction et Exemple et l’utilisation de l’IOC où il faut comprendre « Injection Of Content » plutôt que « Inversion Of Control« .

Ceci est un article orienté publicité d’une part, mais aussi « déploiement ». Toute personne recherchant un framework MVC tombera sur PureMVC ou Cairngorm, et bien maintenant, il y aura aussi ReFlex qui entrera dans la liste.

Si vous utilisez ReFlex, n’hésitez pas à faire des retours à l’auteur.

Edit : Oubli de ma part, gros framework incluant le pattern MVC : Vegas développé par eKameleon. D’ailleurs Vega n’inclue pas uniquement le pattern MVC, mais aussi beaucoup d’autres choses, il peut avoir l’air très difficile à appréhender. Mais comme toute nouvelle découverte, cela demande de l’investissement. Mais rassurez-vous, c’est un framework très riche en documentation.

A vous de faire votre choix