Reprise du message précédent :
Merci skeye.

 
Ca dépend, je peux très bien mettre mon css en bdd    
Mais mettre des images dans le modèle, à moins qu'elles soient stockées en blob dans la bdd, c'est du grand n'importe quoi

Pas nécessairement.
 
Le modèle peut stocker l'image en blob, comme spécifié (potentiellement encodé pour du data:uri)
Le modèle peut stocker un pointeur vers l'image, avec le fichier conservé en externe (le nom ou une partie du chemin de l'image)
Le modèle peut stocker toute l'image quand elle n'est pas un fichier binaire, e.g. le SVG c'est du XML, et même quand il n'y a pas de type XML natif dans la BDD (contrairement aux BDDs de qualité) il est toujours aisé de le stocker en tant que texte.
Enfin, le modèle peut stocker les informations permettant de générer dynamiquement les images
 
Le problème, c'est surtout de savoir si l'image a un intérêt à être stockée dans ou pointée par le modèle, mais c'est pûrement un problème de modélisation, pas technique

Le modèle n'a pas en charge que de récupérer des données stockées en BDD, mais de fournir une interface entre les données (informative sous-entendu), et le reste.
Les données, la plupart du temps, sont stockées en BDD, mais ça peut être complètement autre chose, comme une image par exemple !

Dans un site comme Flickr, par ex, ça te semble pas un peu logique que les images soient manipulées par le modèle ?

Pas vraiment, le modèle pour moi c'est l'interface entre le Contrôleur et les  données contenues dans une base de données.
Mais effectivement, on peut le voir comme une sorte de modèle, une classe qui s'occupe de gérer les images.

 
Ca en fera pas une donnée.

Ben la base de données, c'est qu'une source de données parmi d'autres.

C'est pas une question de BDD, le modèle c'est au mieux toute la couche métier du programme, au pire juste la source de données (bdd et/ou autre). Dans tous les cas, les images d'un site d'images en font partie.

quelqu'un aurait un framework fait maison sous la main ?

J'aurai cela de prévu chez moi, gérer les images individuelles comme les galeries.

Je moinsso ta theorie car c'est completement irrealiste et ce dans n importe quel langage ...

C'est typiquement la base d'un projet foireux e.g un modele trop lourd, une presence trop lourde du langage server side alors que finalement une app. Web c'est fait pour sortir des strings rien de plus.

Quand au RDBMS, Mysql est *tres* bon sur le SELECT ... Ah mais c'est vrai si ya pas une couche native  pour les transactions c pas bien :$

On peut tout faire mais on ne doit meme pas penser a le faire !

Nan mais descend de ton chapiteau

Trop cool, tout le monde est super impressionné

Tu voudrais pas retourner jouer dans ton bac à sable stp?

Monsieur est un aficionado des ressources illimites ?

Ok, lol.
Tu repasseras quand tu auras bossé sur autre chose que des forums en php avec 3 utilisateurs, steuplé.

3 mots: Top 100 alexa

Bye

Et ça fait de toi un top-level du MVC ?
 
Edit : http://java.sun.com/blueprints/pat [...] ailed.html

Dans "enterprise data", il n'y a pas que données venant de BDD !
Faut vraiment que tu descendes de ton petit nuage !

MVC c juste un pattern par contre chez KFC on trouve du poulet - Je dis que le value object qui circule dans les couches de ton design *ne doit pas etre* lourd.

D'ou le : "pas d'objet|structure important(e)". Exemple typique : un objet de vue.

C'est bien beau de vouloir faire de joli design -_-

...et ça fait de toi un expert?
Un type qui raconte des conneries du genre de celles que tu as sorties plus haut c'est un guignol, ni plus ni moins.

Non, monsieur est un aficionado des outils de qualité et d'utiliser le bon outil en fonction du besoin, pas d'utiliser la première merde qui passe parce que c'est ce qu'on a utilisé toute sa vie.

4 mots: tu n'y es pas.

C'est cool, ce que tu racontes n'a même pas de sens

C'est vrai, les trucs genre maintenabilité ou intégrité des données ça ne sert à rien.

PS: tu ne devrais pas essayer d'imaginer taz, tu n'as pas les qualifications pour.

Apres je suis pas la pour te convaincre    
Je savais que ca te casserais le cul, tu px raconter toutes les conneries que tu vx ...
 
Je changerais pas d'opinion a partir du moment ou ce que fais marche bien.

Si t'es incapable de comprendre que pour certaines applis, y compris web, les images font partie des données, et doivent être référencées dans la base d'une manière ou d'une autre, je pense qu'un jour où l'autre tu te rendras compte que ce que tu ne fais ne marche PAS bien...

Dans le modèle

Voir la possibilité 2 de ma liste, qui correspond à un stockage de l'image dans le modèle, mais ne stocke jamais cette image (ou ce média, plus généralement) dans une BDD et est le système utilisé par la majorité des sites manipulant des médias

oué, mais c'est le problème de la base de données qui semblait le chagriner vraiment, alors j'ai simplifié.

C'est vrai, il ne faut pas se moquer des gens en difficulté ou leur rendre la vie plus compliquée qu'elle ne l'est déjà
 
Vive les baskets à scratch

Est-ce que tu peux reformuler ton opinion, parce que je pige rien à tes dix derniers posts

Il dit qu'avoir des objets de poids important dans le modèle, c'est forcément mal.
Et on lui répond qu'il est idiot de croire que c'est aussi simple.

Il veut les mettres où

aucune idée. J'ai surtout l'impression qu'il a jamais eu à traiter autre chose que de petites chaines de caractères dans les 3 sites qu'il a créés dans sa vie...

DTC of course

Ptain j'ai lancé un 'E-Penis battle'
Heureusement qu'on est pas tous dans la même pièce, ça se finirait surement à l'arme à feu

Dans la même pièce, on aurait une discussion posée et adulte. Mais on est sur un forum, alors c'est la guerre.

Dans la même pièce, tout le monde ignorerait complètement les interventions d'un type qui dit qu'avoir une référence à des images dans le modèle "est completement irrealiste" et "typiquement la base d'un projet foireux"...

Aussi oui

 
 
 
Yop
 
Typiquement t'as les couches de ton design, pour le Web M <value_object> V <value_object> C <value_object> M
 
J'essaye d'expliquer que l'objet qui circule dans et entre tes couches (interface, proxy en recepteur) doit etre le plus simple et court possible.
 
Le mal serait dans un ce cas un composite qui contient une dizaine d'object, qui contiennent ... je sais pas un string BLOB.
 
Ca s'etend au traitement implicitement.
 
 
Si ton script prend 100ms a s'executer, tu sers pas plus de 10page/sec (pauvre CPU). D'ou le besoin de reverse proxy, et de plusieurs serveurs applicatif , de RAM ... ca ne s'arrete plus niveau ressource humaine et technique    
 
Edit: PHP qui tape dans la memoire c'est le mal.
 
Prevenir avant de guerir -_-

Et comment fais-tu pour gérer tes strings BLOB et apparentés?

Nan mais si ton modèle ne fait que pointer l'image (juste son URL par exemple), y'a pas de BLOBL qui traîne

 
Ce que tu refuses de comprendre c'est qu'il n'y a pas forcément le choix. Et de toute manière "premature optimization is the root of all evil".

 Pour le moment t'as rien expliqué du tout, t'as déclaré de manière totalement arbitraire

Oui voila oui...

Il n'y a pas de rapport direct avec ce qui est au dessus, mais nm...

T'as raison, PHP s'exécute dans un espace quantique externe, il ne prend jamais de mémoire...