Discussion :

[topolino]

Dans ton archi MVC tu as bien une couche DAL (data access layer), BLL (Business logic layer) et Intergace graphique.

[Immobilis]

J'ai pas d'archi MVC mais 3-Tiers classique BO, UI, BLL, DAL.
Y'a pas de traitement particulier (le moins possible) dans mon UI. C'est le role de la BLL. Ainsi je peux aussi bien faire une appli console que web. Donc franchement je vois pas l'intérêt du MVC. Je trouve mm cela plutôt risqué (court circuit du controleur, mais le controleur n'est pas la BLL). C'est pour cela que j'aimerai mieux comprendre de quoi il s'agit.

A+

[Aizen64]

L'utilisation d'un tel code (interfaces) permet de changer de base de données sans revoir aucune ligne de code.

Comment ça, sans revoir aucune ligne de code ? Par définition, une interface ne fait rien du tout, les méthodes qui y sont associées doivent être réécrites pour une utilisation spécifique.

l'interface graphique se contente d'émettre des événements lorsqu'une action est démandée.
Elle implement l'interface.

Dans tous les cas, peut importe le as d'utilisation, la couche de présentation de données, la vue (interface graphique) doit contenir le code qui transmet les données contenues dans des contrôles aux différentes couches de l'application, que ce soit à la couche métier pour des traitements ou à une base de données.

Je comprends le principe quand même, disons que dès qu'on voit un certains traitements ayant un certain rapport entre eux, utiliser une interface permet à d'autres classes d'implémenter quasiment n'importe quel comportement sans aucune contrainte.

Dans un site web, qu'est ce que tu veux dire par un évènement ? C'est pas tout à fait la même chose qu'une application "classique", un évènement est souvent déclenché par un clic sur un bouton, le bouton renvoie vers une page qui exécute un script pour récupérer, valider et renvoyer un résultat. Là je prends un exemple pour un site PHP, pour .NET les "évènements" web doivent plus ou moins être similaires.

[Immobilis]

Comment ça, sans revoir aucune ligne de code ? Par définition, une interface ne fait rien du tout, les méthodes qui y sont associées doivent être réécrites pour une utilisation spécifique.

Oui, une interface n'a pas de code. Elle se contente d'enoncer des propriété, des méthodes.

Par contre, en instanciant un objet au travers de son interface me permet de manipuler l'objet toujours de la même façon. Dans le cas d'un accès aux données, l'ouverture d'une connexion se fait toujours de la même façon quelque soit le fournisseur de données. Dans le code ci-dessous tu peux remarquer qu'à aucun moment je ne manipule explicitement un objet SQL. C'est la méthode "DbProviderFactories.GetFactory" qui va me fournir mon objet en fonction du provider spécifié dans la chaine de connexion. Ainsi, ce code fonctionnera toujours, quelque soit la base de données que j'utiliserai.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public static void Select()
{
    // Creation de la fabrique
    DbProviderFactory factory = DbProviderFactories.GetFactory(ConfigurationManager.ConnectionStrings["ChaineDeConnexion"].ProviderName);
    // Objet connection
    using (IDbConnection connection = factory.CreateConnection())
    {
        connection.ConnectionString = ConfigurationManager.ConnectionStrings["ChaineDeConnexion"].ToString();
        connection.Open();
        // Objet Command
        using (IDbCommand command = factory.CreateCommand())
        {
            command.CommandText = "SELECT * FROM usr_contract";
            // Object datareader
            using (IDataReader reader = command.ExecuteReader())
            {
                while (reader.Read())
                {
                    for (int i = 0; i < reader.FieldCount; i++)
                    {
                        if (reader[i] != DBNull.Value)
                            Console.Write(reader[i].ToString());
                        else
                            Console.Write("NULL");
                        if (i < reader.FieldCount)
                            Console.Write("|");
                    }
                    Console.WriteLine();
                }
            }
        }
    }
}

utiliser une interface permet à d'autres classes d'implémenter quasiment n'importe quel comportement sans aucune contrainte.

Tu peux préciser?

A+

[Aizen64]

Je veux dire par là, qu'il est possible d'étendre les actions d'une classe indéfiniment. C'est difficile à expliquer, disons que le fonctionnement fait penser à un plug-in.

[Immobilis]

Je veux dire par là, qu'il est possible d'étendre les actions d'une classe indéfiniment. C'est difficile à expliquer, disons que le fonctionnement fait penser à un plug-in.

Désolé, je ne vois pas.

Une interface ne sert qu'à obliger les classes qui l'implémente à présenter les mêmes propriétés et méthodes. Tu instancies ensuite les objets et manipule les interfaces.

A+

[Immobilis]

Il pilote l'interface graphique.

C'est pour cela que l'ui peut etre facilement changé. Il fait la relation entre ce que veux l'ui et ce que lui transmets la BLL

J'ai trouvé cet article qui cela en évidence: http://msdn.microsoft.com/fr-fr/magazine/cc337884.aspx

Il s'agit effectivement d'un pilotage. Le controleur génère les pages web en instanciant les classes en fonction des requêtes.

Il faut que j'arrive à cerner l'intérêt. En extrapolant cela reviendrait à n'avoir qu'une seule page ASPX dont le contenu serait généré à la volée?

A+

[Aizen64]

Je reviens tardivement sur le sujet, je suis en train de regarder de la doc. venant de Microsoft, un PDF : "Web Architecture Pocket". C'est pas mal un document de 145 pages pour de la doc. de poche. Je comprends pas trop ce qui suit :


You should not mix different types of components in the same logical layer. For example, the User Interface (UI) layer should not contain business processing components. Instead, the UI layer should contain components used to handle user input and process user requests

et ça :

For example, a UI processing component should not contain data access code.

Les 2 se rejoingnent. Maintenant il faudrait l'expliquer un truc... Comment ne pas mettre de méthodes d'accès au données ? Je prends un exemple à la con. J'ai une application qui fait une simple division OK ? Tu saisis un nombre et tu mets un autre pour savoir par quel nombre le diviser. Tu cliques sur un bouton OK et hop, t'as le résultat.

L'évènement du bouton devrait contenir un truc comme ça, après avoir converti les données en types "calculables", int float... :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Resultat = Calculs.Diviser(NombreADiviser, Diviseur);

Il y a forcément un moment ou on fait transiter les données. Y-a t-il une autre méthode ?

[Immobilis]

Comment ne pas mettre de méthodes d'accès au données ?

Dans ce cas il s'agit d'accès aux données provenant d'une base et pas du résultat d'une opération.

L'architecture en couche se base sur au moins un principe: une couche ne peux communiquer qu'avec les couches qui lui sont immédiatement adjacentes grâce aux DTO (Data Transfer Objects). Ce sont des classes inertes sans méthodes, elles ne comportent que des propriétés des "accesseurs". Cela permet de découpler les classes et de les rendre plus facile à maintenir.

You should not mix different types of components in the same logical layer. For example, the User Interface (UI) layer should not contain business processing components. Instead, the UI layer should contain components used to handle user input and process user requests

Une interface utilisateur ne fait que recueillir des données de l'utilisateur et présenter celles qu'elle reçoit de la couche métier. J'ai pris pour habitude de faire tous mes développements en console avant de les passer en Web. Ainsi, je ne suis pas dépendant de l'interface. L'interface ne me permet que de faire de l'ergonomie. Mais toutes mes programmes fonctionnent avant en console.

J'ai une application qui fait une simple division OK ? Tu saisis un nombre et tu mets un autre pour savoir par quel nombre le diviser. Tu cliques sur un bouton OK et hop, t'as le résultat.

Il n'y a pas de métier dans une division. Par contre, pour calculer une marge, oui. En console ou en web, le programme te demandera de taper deux nombres: le prix d'achat et le prix de vente.
Si tu n'utilises pas de BLL, tu devras dupliquer le code pour faire ce calcul. Par contre, si tu utilises une couche métier tu transmettras ces deux nombres à la BLL pour obtenir la marge. Le code ne sera pas dupliqué et la maintenance sera facile.

L'évènement du bouton devrait contenir un truc comme ça, après avoir converti les données en types "calculables", int float...

En web

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

monlabel.Text = BLL.Finance.CalculMarge(prixAchat, prixVente).ToString();

En console

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Console.WriteLine(BLL.Finance.CalculMarge(prixAchat, prixVente).ToString());

C'est la même chose pour la DAL. Seule la BLL est autorisée à communiquer avec. La BLL a besoin d'un jeux de données, une liste de client par exemple. Une fois que le format est determiné (XML, DataTable, List<object>, DataSet, CSV, ...) la BLL ne se préocupe pas de savoir quels moyens la DAL va employer pour se procurer ces données (Web service, base Oracle, SQL, ...). Du moment que tu livres les données que la BLL attend tout se passe bien. Tu peux même changer de source de données en cours de route.

Je te suggère de lire les post "Important" du forum de conception suivant: http://www.developpez.net/forums/f94.../architecture/. Ils sont interessants.
A+

[Aizen64]

L'architecture en couche se base sur au moins un principe: une couche ne peux communiquer qu'avec les couches qui lui sont immédiatement adjacentes grâce aux DTO (Data Transfer Objects). Ce sont des classes inertes sans méthodes, elles ne comportent que des propriétés des "accesseurs". Cela permet de découpler les classes et de les rendre plus facile à maintenir.

C'est là que j'ai du mal à comprendre leur intérêt et leur implémentation.

Pour en revenir au niveau du MVC, j'ai toujours une idée très obscure de son utilité. C'est dans l'IHM que je récupères les données que je peux utiliser (via les évènements), qu'est ce que le contrôleur vient foutre la dedans ? Dit autrement, si j'ai une classe "Contrôleur", quelles méthodes peut-il contenir ?

[Immobilis]

C'est là que j'ai du mal à comprendre leur intérêt

Je te cite: http://www.developpez.net/forums/m4109363-2/

ça serait une bonne idée d'avoir une classe à part qui s'occupe d'exécuter toute opération sur la base de données. Comme ça tu as tout de centralisé.

C'est là que j'ai du mal à comprendre (...) leur implémentation.

Rien de plus simple. Pour commencer, une solution .Net vide dans laquelle tu ajoutes:

1. 3 projets bibliothèques de classes nommés ainsi (les noms ne sont pas obligatoires pour que ça fonctionne mais c'est plus clair ainsi):
   
   • BusinessObjects (BO) référençant personne
   • BusinessLogicLayer (BLL) référençant BO et DAL
   • DataAccessLayer (DAL) référençant BO
2. 1 projet application console référençant BO et BLL
3. 1 projet application web référençant BO et BLL

L'ordre de compilation sera automatiquement BO, DAL, BLL, UI

Tu développes en console et tu mets en page en web (ou en winform si tu préfères).

L'architecture obtenue sera celle-ci:

A+

[topolino]

A quoi te sers l'application console ? pourquoi dev en console si c'est pour un site web ?

[Immobilis]

A quoi te sers l'application console ? pourquoi dev en console si c'est pour un site web ?

Permet de gager de la qualité de l'architecture car indépendant de l'interface utilisateur. Ce qui marche en console marchera forcement pour le web et le win. Tout le reste est une question de mise en page.

[Immobilis]

Une révolution http://www.asp.net/mvc/ ?

A+