14-10-2009, 07:51 PM
(Modification du message : 17-10-2009, 11:11 AM par Sephi-Chan.)
J'aime les DAO, j'utilise ActiveRecord (c'est celui par défaut de Ruby on Rails). Pour un jeu par navigateur, les avantages sont conséquents et les défauts moindres.
Parmi les avantages les plus évident : la facilité de maintenance et la fiabilité.
Je prends l'exemple d'un modèle de mon jeu (à l'heure où j'écris les lignes, il est encore assez basique). Il s'agit du modèle Neighbourhood qui modélise un lien de voisinage (unilatéral) entre deux territoires.
D'une, on peut spécifier les association du modèle. Si j'ai un objet Neighbourhood, je peux facilement récupérer son territoire source (en appelant la méthode territory) et son territoire de destination (avec la méthode neighour). Cela me renverra des objets Territory qui auront eux-même leurs propres associations (par exemple en appelant la méthode neighbours sur un objet territoire, j'obtiens tous les territoires associés (grâce à une relation plusieurs-à-plusieurs qui utilise Neighbourhood comme modèle de de jointure).
De plus, les règles de validations rendent le modèle fiable. C'est centralisé, on ne risque jamais de l'oublier.
En plus des règles de validation (très riches), on peut mettre des callbacks (avant/après la validation, avant/après la sauvegarde (et on peut différencier création et modification), avant/après la destruction, etc), donc à nouveau ça permet une centralisation très claire.
Parmi les défauts, on a les performances. Bien sûr si je fais User.all avec une table de 15 000 utilisateurs, ça va prendre un peu de temps d'instancier autant d'objets, mais on fait rarement ce genre de choses…
L'autre avantage aussi, c'est que l'objet permet très simplement d'ajouter un système de cache : il suffit de modifier les accesseurs.
Enfin, car ça peut en rebuter, le SQL est généré intelligemment.
Il y a moyen de faire beaucoup de choses avant d'avoir besoin de taper du SQL à la main (et ça reste très simple à faire).
Pour les sceptiques à propos de l'efficacité des requêtes générée, une petite vidéo qui montre en action deux outils qui permettent de générer des jointures include et join (ou non, selon les cas).
Sephi-Chan
Parmi les avantages les plus évident : la facilité de maintenance et la fiabilité.
Je prends l'exemple d'un modèle de mon jeu (à l'heure où j'écris les lignes, il est encore assez basique). Il s'agit du modèle Neighbourhood qui modélise un lien de voisinage (unilatéral) entre deux territoires.
class Neighbourhood < ActiveRecord::Base
belongs_to :territory
belongs_to :neighbour, :class_name => 'Territory',
:foreign_key => :neighbour_id
validate :check_uniqueness_of_association
validate 
ource_and_neighbour_are_different
protected
# Can't have to neighbourhoods with the same territories.
def check_uniqueness_of_association
existant_equivalent = Neighbourhood.find_by_territory_id_and_neighbour_id(
territory_id,
neighbour_id
)
errors.add_to_base(:already_defined) if existant_equivalent
end
# The source territory can't be the neighbour territory.
def source_and_neighbour_are_different
errors.add_to_base(ame_territories) if territory == neighbour
end
end
D'une, on peut spécifier les association du modèle. Si j'ai un objet Neighbourhood, je peux facilement récupérer son territoire source (en appelant la méthode territory) et son territoire de destination (avec la méthode neighour). Cela me renverra des objets Territory qui auront eux-même leurs propres associations (par exemple en appelant la méthode neighbours sur un objet territoire, j'obtiens tous les territoires associés (grâce à une relation plusieurs-à-plusieurs qui utilise Neighbourhood comme modèle de de jointure).
De plus, les règles de validations rendent le modèle fiable. C'est centralisé, on ne risque jamais de l'oublier.
En plus des règles de validation (très riches), on peut mettre des callbacks (avant/après la validation, avant/après la sauvegarde (et on peut différencier création et modification), avant/après la destruction, etc), donc à nouveau ça permet une centralisation très claire.
Parmi les défauts, on a les performances. Bien sûr si je fais User.all avec une table de 15 000 utilisateurs, ça va prendre un peu de temps d'instancier autant d'objets, mais on fait rarement ce genre de choses…
L'autre avantage aussi, c'est que l'objet permet très simplement d'ajouter un système de cache : il suffit de modifier les accesseurs.
Enfin, car ça peut en rebuter, le SQL est généré intelligemment.
Il y a moyen de faire beaucoup de choses avant d'avoir besoin de taper du SQL à la main (et ça reste très simple à faire).
Pour les sceptiques à propos de l'efficacité des requêtes générée, une petite vidéo qui montre en action deux outils qui permettent de générer des jointures include et join (ou non, selon les cas).
Sephi-Chan