Quel pattern choisir pour une architecture multi-site?

Version imprimable

12/08/2009, 20h51
Leelith

Quel pattern choisir pour une architecture multi-site?

Bonsoir!

Je me pose la question suivante: dans une solution que je developpe, je souhaite proposer 3 versions (2 online et une offline).

J'ai fais l'erreur de me lancer dans le projet tête baissée, et au fur à mesure que j'avance, je me rend compte que ça va être impossible de maintenir et de faire évoluer mes 3 solutions.

J'ai pensé au modèle MVC, puis de créer un répertoire à la racine pour mes 3 différentes solutions. Je peux comme ça les faires évoluer indépendamment. Le seul problème c'est qu'en faite les fonctions de la solution la plus basique sont également utilisé dans les 2 autres solutions plus complexe. Je ne sais donc pas vers quoi m'orienter ou si mon idée est bonne et fonctionne avec MVC.

Le seul point dont je suis normalement sur, c'est qu'il y aura 3 bases de données: 1 pour chaque solution, ceci afin de ne pas avoir de problèmes de performances en cas de sollicitations.

Merci pour votre aide!

L.
14/08/2009, 00h09
Immobilis

Salut,

Je comprend pas bien ton problème...

3 versions d'une application = 2 online + 1 offline. Pourquoi 2 online? C'est quoi la solution basique? Pourquoi 3 bases de données?

A+
14/08/2009, 09h12
Leelith

Citation:

Envoyé par Immobilis

Salut,

Je comprend pas bien ton problème...

3 versions d'une application = 2 online + 1 offline. Pourquoi 2 online? C'est quoi la solution basique? Pourquoi 3 bases de données?

A+

Salut. 2 online, parce que 1 sera gratuite, et l'autre payant (fonctionnalité supplémentaire).

Pour les bases de données, j'ai pensé à des bases indépendantes pour chaque solution pour ne pas surcharger trop les bases à partir du moment ou j'atteindrais un certains nombre d'utilisateurs. Est-ce que ce n'est pas la meilleure solution?

Merci ;)
14/08/2009, 09h41
julien_iz

Voici mon opinion, sans connaitre le vrai contenu du projet:

Citation:

Envoyé par Leelith

Salut. 2 online, parce que 1 sera gratuite, et l'autre payant (fonctionnalité supplémentaire).

Pourquoi ne pas simplement faire un système de compte "prenium" (comme le font beaucoup de sites) donnant accès a plus de section dans le site? Cela éviterait de coder le site en double. ;)

Concernant la version offline, quelle est la techno utilisée?

Je ne vois pas l'intérêt de faire une BDD pour la version offline:
-soit tu es vraiment offline et donc l'appli ne se connectera pas a la bdd
-soit tu veux dire par la "client lourd" et peut etre qu'une bdd commune avec l'autre version serait une bonne chose pour permettre aux utilisateur de passer d'une version a l'autre facilement

Personnellement, j'aurais tendance a faire 2 version avec une seule BDD, mais après tout dépend du projet.....
14/08/2009, 11h04
Leelith

Citation:

Envoyé par julien_iz

Voici mon opinion, sans connaitre le vrai contenu du projet:

Pourquoi ne pas simplement faire un système de compte "prenium" (comme le font beaucoup de sites) donnant accès a plus de section dans le site? Cela éviterait de coder le site en double. ;)

Concernant la version offline, quelle est la techno utilisée?

Je ne vois pas l'intérêt de faire une BDD pour la version offline:
-soit tu es vraiment offline et donc l'appli ne se connectera pas a la bdd
-soit tu veux dire par la "client lourd" et peut etre qu'une bdd commune avec l'autre version serait une bonne chose pour permettre aux utilisateur de passer d'une version a l'autre facilement

Personnellement, j'aurais tendance a faire 2 version avec une seule BDD, mais après tout dépend du projet.....

Pour la version Premium, ça ne pose pas trop de contrainte de devoir à chaque fois vérifier si l'utilisateur est premium ou pas pour avoir droit à certaines fonctions? Si ça ne pose pas de problème, dans ce cas je peux faire également pareil pour ma version off-line (qui est cencée avoir plus de fonctionnalités).

ça ne risque pas de poser trop de problème que d'avoir mes deux versions online qui tourne sur la même base? C'était plus pour décharger l'utilisatio de la base de donnée que j'avais pensé à faire une solution par base de donnée.

En faite, par offline je voulais dire en intranet ^^ donc la technologie utilisée serait c# asp.net ;)
14/08/2009, 11h23
Philippe Vialatte

ok, donc tu as 3 sites web avec 3 niveaux de fonctionnalité différente...qui doivent acceder a trois bases de donnees...mais qui sont en fait un seul site avec des niveaux d'acces differents ?

Ce serait bcp plus simple d'avoir un seul site, avec une gestion de droits d'acces, genre 3 groupes (standard, premium, admin), et des niveaux d'acces differents...

Citation:

ça ne pose pas trop de contrainte de devoir à chaque fois vérifier si l'utilisateur est premium ou pas pour avoir droit à certaines fonctions?

ca coute peanuts ;)...et tu as deja des mécanismes tout faits dans le framework...

Citation:

ça ne risque pas de poser trop de problème que d'avoir mes deux versions online qui tourne sur la même base? C'était plus pour décharger l'utilisatio de la base de donnée que j'avais pensé à faire une solution par base de donnée.

Personnelement, je pense que ta solution est mauvaise...dans le sens ou il faut gerer le passage des utilisateurs de la version standard a premium, et la gestion des deux comptes par les admins (si j'ai bien compris ton pb...), ca rajoute de la complexite de facon inutile.

Il vaut mieux partir d'une base unique, que tu optimise comme il faut, quitte a faire une repartition de la charge en faisant un cluster de bases...ceci dit, je connais des sites qui gerent quelques dizaine de milliers d'utilisateurs quotidiens avec une seule base de donnees, alors avant de planifier le split de tes bases, commence par une seule base, et vois si tu es bloque ;)
14/08/2009, 11h36
Leelith

Citation:

Envoyé par Philippe Vialatte

ok, donc tu as 3 sites web avec 3 niveaux de fonctionnalité différente...qui doivent acceder a trois bases de donnees...mais qui sont en fait un seul site avec des niveaux d'acces differents ?

Ce serait bcp plus simple d'avoir un seul site, avec une gestion de droits d'acces, genre 3 groupes (standard, premium, admin), et des niveaux d'acces differents...

ca coute peanuts ;)...et tu as deja des mécanismes tout faits dans le framework...

Personnelement, je pense que ta solution est mauvaise...dans le sens ou il faut gerer le passage des utilisateurs de la version standard a premium, et la gestion des deux comptes par les admins (si j'ai bien compris ton pb...), ca rajoute de la complexite de facon inutile.

Il vaut mieux partir d'une base unique, que tu optimise comme il faut, quitte a faire une repartition de la charge en faisant un cluster de bases...ceci dit, je connais des sites qui gerent quelques dizaine de milliers d'utilisateurs quotidiens avec une seule base de donnees, alors avant de planifier le split de tes bases, commence par une seule base, et vois si tu es bloque ;)

Citation:

Envoyé par Philippe Vialatte

ok, donc tu as 3 sites web avec 3 niveaux de fonctionnalité différente...qui doivent acceder a trois bases de donnees...mais qui sont en fait un seul site avec des niveaux d'acces differents ?

Exactement.

Citation:

Envoyé par Philippe Vialatte

ca coute peanuts ;)...et tu as deja des mécanismes tout faits dans le framework...

Ca, c'est la nouvelle dont j'avais besoin :ccool::D

Citation:

Envoyé par Philippe Vialatte

ok, donc tu as 3 sites web avec 3 niveaux de fonctionnalité différente...qui doivent acceder a trois bases de donnees...mais qui sont en fait un seul site avec des niveaux d'acces differents ?

Ce serait bcp plus simple d'avoir un seul site, avec une gestion de droits d'acces, genre 3 groupes (standard, premium, admin), et des niveaux d'acces differents...

ca coute peanuts ;)...et tu as deja des mécanismes tout faits dans le framework...

Si tu as plus d'informations là-dessus, je prend volontiers :)

Tu as effectivement raison dans le cas du transfère d'utilisateurs, c'est dailleurs un des problèmes que j'avais déjà pensé.

Citation:

Envoyé par Philippe Vialatte

Il vaut mieux partir d'une base unique, que tu optimise comme il faut, quitte a faire une repartition de la charge en faisant un cluster de bases...ceci dit, je connais des sites qui gerent quelques dizaine de milliers d'utilisateurs quotidiens avec une seule base de donnees, alors avant de planifier le split de tes bases, commence par une seule base, et vois si tu es bloque ;)

C'est possible de faire pareil avec SQL Server Express? Je n'ai aucune idée des fonctionnalités et possibilité en terme de performance mise à disposition pour SQL Server Express.
14/08/2009, 13h56
julien_iz

La version express de sql server limite le nombre de connexion simultanée me semble-t-il.

Après, rien ne t'empêche d'utiliser un autre SGBD (par rapport a ce que tu as dit jusqu'à maintenant)
14/08/2009, 22h14
Kaidan

Je ne crois pas que SQL Server Express limite le nombre de connexions simultannées. Par contre, il limite la taille de la base (4 Go), la taille de la mémoire vive utilisable (1 Go, ce qui va pénaliser les performances dès que la base fait plus 1 Go) et l'utilisation du processeur à un seul processeur (un seul core pour les dual-quad core ce qui pénalise les performances en cas de nombreux accès concurrents).
14/08/2009, 22h20
Philippe Vialatte

Si tu es inquiet de la montée en charge de ton appli, oublie la version express ;)...une base de 4Go, l'aitr de rien, sur une appli un peu utilisée, on peut y arriver très vite...

Tu peux passer à la version pro, ce qui t'enlèverait ces limitations, ou à du MySQL, ce qui serait gratos (mais pas completement sans consequences cote dev...)
14/08/2009, 23h17
Leelith

J'ai jetté un coup d'oeil aux prix :cry: je ne peux pas me permettre d'acheter une licence enterprise. Je suis pour l'instant à mon compte, et comme mon business n'est pas encore lancé et que je débute, je ne peux pas supporter un coup comme ça même en ayant un emploi à côté :/ (http://www.microsoft.com/sqlserver/2...s/pricing.aspx)

Du côté d'Access, ce n'est pas assez performant
14/08/2009, 23h24
Philippe Vialatte

Pas access....MySQL ;)

Après, charge a toi de coder proprement pour que ton appli ne soit pas fortement couplée à la base de données :D

Dans le pire des cas, commence avec SQL Express, si tu arrives aux limites, passe a MySQL, et si tu arrives aux limites....bah la, si tu arrives aux limites de MySQL, c'est que tu aura de toute façon plein de clients ;)
14/08/2009, 23h31
Leelith

Citation:

Envoyé par Philippe Vialatte

Pas access....MySQL ;)

Après, charge a toi de coder proprement pour que ton appli ne soit pas fortement couplée à la base de données :D

Dans le pire des cas, commence avec SQL Express, si tu arrives aux limites, passe a MySQL, et si tu arrives aux limites....bah la, si tu arrives aux limites de MySQL, c'est que tu aura de toute façon plein de clients ;)

Access n'est pas performant?

Et pour MySQL, ce n'est pas trop compliqué de l'utiliser avec c# asp.net?

Sinon pour le codage de la base de données, je pensais faire une classe qui en faite contient les methodes d'accès à la base de donnée. Dans un autre fichier config j'aurais la base sélectionnée, et en fonction de la base, ça appelle tel ou tel requête de connexion (vu que le langage SQL ne change pas). Je sais plus si ça s'appelle un wrapper ou un mapping object, mes cours d'UML et de programmation sont loins :D
15/08/2009, 00h26
Philippe Vialatte

Citation:

Envoyé par Leelith

Access n'est pas performant?

A eviter pour un developpement pro ;)

Citation:

Et pour MySQL, ce n'est pas trop compliqué de l'utiliser avec c# asp.net?

Pas vraiment plus difficile qu'une autre base de données, grace a la magie des providers :)

Citation:

Sinon pour le codage de la base de données, je pensais faire une classe qui en faite contient les methodes d'accès à la base de donnée.

Si tu n'as qu'une expérience limité en .Net (ce qui semble etre le cas), je te conseille fortement de te documenter un peu sur l'existant en terme d'ORM, sinon, tu as...allez, a peu pres 90% de chance de te planter la premiere fois, et de ne réussir à faire qq chose qui ne tienne la route qu'au bout de plusieurs essais longs et douloureux (et, oui, je parle d'experience ;) )
15/08/2009, 01h13
Immobilis

Salut,

J'ai quelques exemples de code en 3 tiers totalement indépendants du fournisseur de données. En résumé, il faut travailler avec des procédures stockées et des interfaces: http://dotnet.developpez.com/faq/asp...onet_procstock

A+
15/08/2009, 22h12
Leelith

Citation:

Envoyé par Philippe Vialatte

A eviter pour un developpement pro ;)

Pas vraiment plus difficile qu'une autre base de données, grace a la magie des providers :)

Si tu n'as qu'une expérience limité en .Net (ce qui semble etre le cas), je te conseille fortement de te documenter un peu sur l'existant en terme d'ORM, sinon, tu as...allez, a peu pres 90% de chance de te planter la premiere fois, et de ne réussir à faire qq chose qui ne tienne la route qu'au bout de plusieurs essais longs et douloureux (et, oui, je parle d'experience ;) )

J'ai regardé un peu, j'ai vu qu'il y a un framework iBatis qui fait ça, mais si tu dis que .Net fait déjà ça, est-ce que tu peux me dire quels classes de .Net effectue ce même job? Par contre, je ne suis pas sûr que ça resolve le problème de dépendance à une base de donnée, non?

@Immobilis: Si tu as des exemples un peu plus concret, je prend volontiers :)
15/08/2009, 22h23
Philippe Vialatte
Citation:

Envoyé par Leelith

J'ai regardé un peu, j'ai vu qu'il y a un framework iBatis qui fait ça, mais si tu dis que .Net fait déjà ça, est-ce que tu peux me dire quels classes de .Net effectue ce même job? Par contre, je ne suis pas sûr que ça resolve le problème de dépendance à une base de donnée, non?

Tu n'as pas de "classes" qui fassent de l'ORM en.Net, mais tu as du choix...

Tu as effectivement Ibatis, mais aussi NHibernate, Linq To SQL, Entity Framework, LLBLGEN, Subsonic, et une belle quantité d'autres...

Le choix qu'il te faut faire, c'est principalement en terme de tes besoins de fonctionnalités avancées ou pas, typiquement NHibernate peut tout faire, mais est plus long a apprendre, EF, c'est à peu prés pareil, Linq To SQL, LLBLGEN ou Subsonic sont plus simples, mais atteignent leurs limites pour des domaines métiers ou des bases de données complexes

Pour le probleme de dependances à la db, la plupart des ORM te permettent d'écrire qq chose comme :
Code:

1 2 3 4 IList cats = sess.CreateCriteria(typeof(Cat)) .Add( Expression.Like("Name", "Fritz%") ) .Add( Expression.Between("Weight", minWeight, maxWeight) ) .List();
ou
Code:

1 2 3 ProductCollection products = new ProductCollection() .Where(Product.Columns.Color, "red") .Load();
...après, en fonction du fournisseur courant, il vont te générer une requête selon le format de ta base de données, ce qui te permets une certaine indépendance ;)
16/08/2009, 02h09
julien_iz

Citation:

Envoyé par Philippe Vialatte

Tu as effectivement Ibatis, mais aussi NHibernate, Linq To SQL, Entity Framework, LLBLGEN, Subsonic, et une belle quantité d'autres...

Microsoft semble privilégier linq to entities par rapport a linq to sql pour le futur ;-)
16/08/2009, 09h38
Leelith
Citation:
Envoyé par Philippe Vialatte

Tu n'as pas de "classes" qui fassent de l'ORM en.Net, mais tu as du choix...

Tu as effectivement Ibatis, mais aussi NHibernate, Linq To SQL, Entity Framework, LLBLGEN, Subsonic, et une belle quantité d'autres...

Le choix qu'il te faut faire, c'est principalement en terme de tes besoins de fonctionnalités avancées ou pas, typiquement NHibernate peut tout faire, mais est plus long a apprendre, EF, c'est à peu prés pareil, Linq To SQL, LLBLGEN ou Subsonic sont plus simples, mais atteignent leurs limites pour des domaines métiers ou des bases de données complexes

Pour le probleme de dependances à la db, la plupart des ORM te permettent d'écrire qq chose comme :

Code:

1 2 3 4 IList cats = sess.CreateCriteria(typeof(Cat)) .Add( Expression.Like("Name", "Fritz%") ) .Add( Expression.Between("Weight", minWeight, maxWeight) ) .List();

ou

Code:

1 2 3 ProductCollection products = new ProductCollection() .Where(Product.Columns.Color, "red") .Load();

...après, en fonction du fournisseur courant, il vont te générer une requête selon le format de ta base de données, ce qui te permets une certaine indépendance ;)
J'aime bien partir sur une bonne base. Je ne pense pas que j'aurais besoin d'un gros framework pour l'instant, parce que ma base de donnée n'est pas très complexe pour le même: un maximum de 10 tables actuellement.

Selon toi, quel framework m'apporterais plus de faciliter si je dois changer vers un framework plus grand, si plus tard pour les raisons que tu cite je rencontre des problèmes?

@julien_iz: c'est quoi la difference entre Link to SQL et to Entity?
16/08/2009, 12h33
Immobilis

Il y a beaucoup de façons de bien faire et de mal faire. Il y a aussi pas mal de nouveautés. Un bon principe est de découpler au maximum toutes les parties de ton code. C'est-à-dire faire en sorte qu'il y ait le moins de dépendances possibles. Cela est quelque chose de constant. C'est pour cela qu'il est déconseillé de mélanger du code pour récupérer des données avec une interface homme machine par exemple.

Je suis peut-être d'une vieille école mais je suis assez partisant de l'architecture multi-tiers. Elle permet de faire beaucoup de choses. Tu devrais lire ce post: http://www.developpez.net/forums/d24...multi-couches/

A+
16/08/2009, 12h45
Philippe Vialatte

+1 pour le multi-couche, a condition d'aller aussi jusqu'au bout et de faire du MVP (ou MVC) au niveau des vues, sinon, on fait du code lasagnes ;)

Les différences entre Linq to SQL et entity frameworks sont principalement que linq to sql ne marche qu'avec sql server, qu'il n'est pas trés souple pour des bases complexes, et qu'il n'est plus prévu qu'il évolue...

tu trouveras des klistes exhaustives des différences sur internet ;)
16/08/2009, 13h16
Leelith

Je partage ton avis. C'est pourquoi je me pose cette reflexion: je préfère prendre du temps pour faire une architecture correct de mon site, plutôt que d'aller tête baissée (comme j'ai déjà fais).

J'étais parti pour utiliser le design pattern MVC (assez classique dans le web) en fait...

Edit: MVC sépare bien la partie interface-homme-machine, avec le traitement et la logique métier, avec l'accès aux bases de données?
16/08/2009, 13h21
Immobilis

Citation:

Envoyé par Philippe Vialatte

+1 pour le multi-couche, a condition d'aller aussi jusqu'au bout et de faire du MVP (ou MVC) au niveau des vues, sinon, on fait du code lasagnes ;)

Ah, remarque qui m'interesse. On a plutôt tendance à opposer 3-Tiers et MVC. Ou tout du moins de dire que ce sont deux architectures totalement différentes. Selon toi le MVC ou MVP seraient l'aboutissement du 3-Tiers? Le multicouches repose sur du code lasagne comme tu dis alors que le MVC pas du tout.

A+
16/08/2009, 19h44
Philippe Vialatte

En fait, ce sont deux modes d'archi qui sont indépendants, mais si tu fais une belle separation en couche et que ton ihm est un espece de plat de nouilles, tu n'as résolu que 50% des problemes de maintenance de l'appli.

Avec l'experience,j'ai vu plein de projets ou les couches data et metier etaient nickel, mais les pages une horreur avec un page_load de 1800 lignes, qui agregait les responsabilités de sécurité, mapping et validation...

Coté MVC/P, on peut considérer que le M est égal aux couches Data et Business, et le couple VC ou VP à l'IHM, donc dans ce sens, ils peuvent etre complementaires ;)

Disons qu'en appliquant les 2 patterns, on obtient une appli top moumoute (et qu'on le fait bien...) :mrgreen:
16/08/2009, 19h54
Immobilis

Citation:

Envoyé par Philippe Vialatte

les couches data et metier etaient nickel, mais les pages une horreur avec un page_load de 1800 lignes

J'ai du mal à imaginer qu'on puisse faire un truc nickel d'un côté et à ch**r de l'autre...
16/08/2009, 20h13
Philippe Vialatte

Citation:

Envoyé par Immobilis

J'ai du mal à imaginer qu'on puisse faire un truc nickel d'un côté et à ch**r de l'autre...

Eh, tu connais pas certain de mes collègues, alors :D

Edit: pour reformuler, sur un projet lambda, en début de projet, tu fais travailler une ou deux personnes expérimentées, qui te mettent en place l'application, l'archi, l'integration continue et tout et tout...

Avance de trois mois, le projet à été mené à bien, ou ces personnes sont parties sur d'autres projets, la maintenance est donnée à des juniors, etc.. etc...

Avance rapide d'un an, et tu te retrouve avec un machin ignoble ;)
16/08/2009, 20h30
Immobilis

Arf, c'est vrai. J'ai les mêmes à la maison. Cependant, c'est valable pour tout. Y'a pas une techno à l'abri... Seule solution un gourou qui joue les cerbères. Perso, j'ai opté pour une autre option: la démocratie participative. Les règles sont votées en réunion. Le responsable du département devra vérifer le respect des règles. On verra pour les sanctions...
16/08/2009, 20h33
Leelith

Citation:

Envoyé par Philippe Vialatte

En fait, ce sont deux modes d'archi qui sont indépendants, mais si tu fais une belle separation en couche et que ton ihm est un espece de plat de nouilles, tu n'as résolu que 50% des problemes de maintenance de l'appli.

Avec l'experience,j'ai vu plein de projets ou les couches data et metier etaient nickel, mais les pages une horreur avec un page_load de 1800 lignes, qui agregait les responsabilités de sécurité, mapping et validation...

Coté MVC/P, on peut considérer que le M est égal aux couches Data et Business, et le couple VC ou VP à l'IHM, donc dans ce sens, ils peuvent etre complementaires ;)

Disons qu'en appliquant les 2 patterns, on obtient une appli top moumoute (et qu'on le fait bien...) :mrgreen:

comment appliqué les 2 patterns, si les propriétés de l'un correspondent aux propriété de l'autre? Je n'ai pas une grande expérience de tout ça, j'ai suivis mes cours, appliqué quelques patterns comme observer/observable, state, et 2-3 autres mais c'était dans des petits projets...
16/08/2009, 20h48
Immobilis

Citation:

Envoyé par Leelith

comment appliqué les 2 patterns

Pour le moment, je vois pas trop non plus :mouarf: D'autant que VS 2010 à un peu tendance à tout faire.

Citation:

Envoyé par Leelith

comment appliqué les 2 patterns, si les propriétés de l'un correspondent aux propriété de l'autre?

Arf, vaste question (dis le gars qui est en train d'écrire un article sur MVC/MVP...) ;)

grosso modo, si tu es en MVP (si tu es en MVC, un bon point de départ, c'est http://dotnet.developpez.com/mvc...De tête, s'il vous plait ;) ), tu vas avoir les couches suivantes :
DataAccess -> ta couche d'accès aux données
Business -> tes objets métiers + les factorys
Web -> tes pages Web et les presenter

le cycle de vie d'une page, ca va etre :
- l'utilisateur demande la page Client.apsx?Id=5 (par exemple...)
- dans le constructeur de la page Client.aspx, tu vas instancier un objet presenter, qui va prendre en parametre ta page Client.aspx, et lui ajouter toutes les factorys que tu vas utiliser pour manipuler tes objets métiers, dans ce genre la:
Code:

1 2 3 4 5 6 7 8 9 10 public class ClientPage : Page { ClientPresenter _presenter; public Client(){ _presenter = new ClientPresenter(this, new ClientFactory()); } }
Ta vue va aussi exposer des propriétés pour permettre l'accés aux divers champs de ta page, aux propriétés de la querystring, etc...
- Coté ClientPresenter, tu vas faire qq chose comme :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class ClientPresenter : Page { ClientPage _page; ClientFactory _factory public ClientPresenter (ClientPage page, ClientFactory factory){ _page = page; _factory = factory; LoadClient(page.ClientId); } private void LoadClient(int id){ Client objClient = _factory.GetOneClient(id); page.Nom = objClient.Nom; ..... } }
la, j'ai des cloques au doigts (véridique, gadin en escalade), alors je développe pas plus, mais l'idée est la ;)

16/08/2009, 22h03
Leelith

Ok, je vois un peu la chose. Mais la c'est uniquement du MVC?

Ma question finalement, c'est plutôt est-ce qu'on peut faire un code correct, non-spaghetti bolognaise, avec une bonne séparation des traitements? Ceci bien-sûr dans le bute de maintenir facilement le code et de favoriser la réutilisation de code :)

En tout cas, je suis fortement intéressé par ton article ;) Si tu peux me tenir au courant lorsqu'il est dispo, je t'en remercierais grandement :ccool:
16/08/2009, 22h23
Philippe Vialatte

Citation:

Envoyé par Leelith

Ok, je vois un peu la chose. Mais la c'est uniquement du MVC?

Non, dans ce cas, c'est du mvp, donc utilisable avec toutes les versions du framework

Citation:

Ma question finalement, c'est plutôt est-ce qu'on peut faire un code correct, non-spaghetti bolognaise, avec une bonne séparation des traitements? Ceci bien-sûr dans le bute de maintenir facilement le code et de favoriser la réutilisation de code :)

La réponse est oui, mais ce n'est ni gratuit ni trivial ;) Pour la réutilisation de code, à mon avis, ca ne devrait jamais ou presque être une chose à laquelle tu penses pour un projet. A la limite, en fin de projet, dire "ok, ca, c'est réutilisable" et l'extraire du code, mais pas penser à ca quand tu codes

Citation:

En tout cas, je suis fortement intéressé par ton article ;) Si tu peux me tenir au courant lorsqu'il est dispo, je t'en remercierais grandement :ccool:

Bah je pense pas avoir le temps de le finir avant Septembre (plutôt mi-Septembre, d'ailleurs), mais si j'y pense, je te tiens au courant (et sinon, regarde sur la page .net de dvp ;) )
16/08/2009, 22h38
Leelith

Citation:

Envoyé par Philippe Vialatte

Non, dans ce cas, c'est du mvp, donc utilisable avec toutes les versions du framework

La réponse est oui, mais ce n'est ni gratuit ni trivial ;) Pour la réutilisation de code, à mon avis, ca ne devrait jamais ou presque être une chose à laquelle tu penses pour un projet. A la limite, en fin de projet, dire "ok, ca, c'est réutilisable" et l'extraire du code, mais pas penser à ca quand tu codes

Bah je pense pas avoir le temps de le finir avant Septembre (plutôt mi-Septembre, d'ailleurs), mais si j'y pense, je te tiens au courant (et sinon, regarde sur la page .net de dvp ;) )

Quelle est la différence alors entre MVP et MVC?

Pour la réutilisation du code, je prend note du conseil. Et pour l'article, je penserais à y jetter un oeil alors :)
17/08/2009, 01h20
Immobilis

Citation:

Envoyé par Philippe Vialatte

Pour la réutilisation de code, à mon avis, ca ne devrait jamais ou presque être une chose à laquelle tu penses pour un projet. A la limite, en fin de projet, dire "ok, ca, c'est réutilisable" et l'extraire du code, mais pas penser à ca quand tu codes

Alors là je ne suis pas du tout d'accord!!! Il faut au contraire y penser en permanence. C'est quand on ne se pose pas la question qu'on obtient des pages de 1800 lignes qui mèlent l'accès aux données et le métier, qu'on duplique du code alors qu'on aurait pu le mettre en commun, du code spaghetti.

A+
17/08/2009, 07h58
Philippe Vialatte

Euh...tu parles de réutisation dans ton projet ou entre projets ?

si c'est dans le projet, ce n'est pas de la réutilisation, c'est de l'utilisation (application de DRY + SOLID)

si c'est entre projet, chaque référence externe à un composant = un nouveau client = une autre raison de changer le code = une autre raison d'ajouter des bugs

Perso, la seule chose que j'ai jamais réutilisé d'un projet, ,c'était un framework d'accès aux données et un framework de log (et ils ont maintenant été remplacés par des frameworks externes), le reste était spécifique au projet
17/08/2009, 09h50
Arthis

Philippe, j attends ton article sur MVP avec impatience.... J'ai comme l'impression que j'ai commencé à developpé suivant ce modele, mais que je n'ai pas éte encore aussi loin que cá pour l'instant...

Pour ton projet Leelith, je te conseillerais de partir sur du mvc avec si possible un framework d'acces au données mais franchement cela va dépendre du temps que tu pourras réellement accorder à ton projet. A mon avis, si tu travailles correctement de cette facon, tu auras le maximum de latitude pour changer quelque chose ensuite, si l'envie t'en prends.

Bon courage à toi,

Fuseau horaire GMT +2. Il est actuellement 18h30.