Quel pattern choisir pour une architecture multi-site?

Version imprimable

Voir 40 message(s) de cette discussion en une page

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,

Voir 40 message(s) de cette discussion en une page