Discussion :

[Gat-]

Bonjour,

Je suis actuellement sur l'étude d'un projet où les données de la base seront accessibles de plusieurs manières, via une appli. web (multilingue), une appli. winform (wpf, juste FR) et un service qui tournera chaque heure pour faire des stats. Du coup, je me suis lancé sur quelques tests notamment la création d'un projet web ASP.NET MVC3 dans VS2010 mais en déportant le model dans une dll.

Je pensais définir une structure de base simple avec les couches suivantes :

- Une couche Data encapsulée dans une dll : MyProject.Data.dll
Contenant mes classes POCO et ma classe Context permettant d'accéder à la base (classes générées via C# POCO Generator). Ces classes étaient dans le dossier Models du projet ASP.NET MVC3.

- Une couche Core encapsulée dans une dll : MyProject.Core.dll
Contenant mes classes métier effectuant tous les traitements et accès à la base (en passant par les objets de la couche Data).

- Une couche Resources encapsulée dans une dll : MyProject.Resources.dll
Contenant des fichiers ressources avec l'ensemble des libellés pour chaque langue utilisée dans les appli.

Ensuite dans l'idée, les appli web/winform ou services windows n'auraient qu'à faire appelle à ces dll et donc n'effectuer que très peu de traitement. Mais durant mes tests sur le projet ASP.NET MVC3, j'ai vu qu'il n'était pas possible d'ajouter des MetaData aux classes POCO en dehors de la dll "MyProject.Data.dll".

Voici un exemple de ce que j'ai voulu faire :

- Dans MyProject.Data.dll :

Code :

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

1
2
// Déclaration de la classe POCO
public partial class MyClassPoco { /* ... */ }

- Dans MyProject.Core.dll :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
// Association de la classe POCO avec une Metadata
[MetadataType(typeof(MyClassPocoMetaData))]
public partial class MyClassPoco { }
 
// Déclaration de la classe MetaData
public partial class MyClassPocoMetaData
{
    // Ajout de l'attribut Required et StringLength
    [Required]
    [StringLength(128)]
    public string MyDescription { get; set; }
}

- Dans le projet ASP.NET MVC3 :

Code :

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

1
2
3
4
5
6
7
// Déclaration de la classe MetaData
public partial class MyClassPocoMetaData
{
    // Ajout de l'attribut Display
    [Display(Name = "Description", ShortName = "Desc", Description = "Description de la propriété")]
    public string MyDescription { get; set; }
}

Est-ce mon utilisation des MetaData qui n'est pas bonne ?
Est-ce mon découpage en différente couche qui ne va pas ?
Je pensais que c'était une manière propre mais j'ai l'impression d'avoir fait n'importe quoi...

[tomlev]

Ben le problème c'est surtout que les différentes parties d'une classe partielle ne peuvent pas être dans des assemblies différents... sinon à quel assembly appartiendrait la classe ?

A mon avis les entités POCO ne devraient pas être dans l'assembly Data, mais plutôt dans un assembly spécifique (ou éventuellement dans Core). Et la classe de metadata n'a pas forcément besoin d'être dans le projet MVC, tu peux très bien la mettre dans le même assembly que les classes POCO...

[Gat-]

Je m'embrouille pas mal avec l'utilisation des classes POCO générées à partir du modèle de la base (.edmx). Je dois avouer que c'est la premier fois que je le teste. Du coup, je me rend compte que mon problème vient plutôt de ma mauvaise compréhension de l'utilisation des POCO et des MetaData.

Voilà ce que j'ai compris :
- Les classes POCO représentent chaque entité de la base.
- La classe MyContext (qui hérite de ObjectContext) me permet de récupérer les données sous forme de collection d'objets POCO mais aussi de créer / mettre à jour / supprimer (via un DetectChanges & SaveChanges)
Du coup, je me suis dit que cela représentait la couche d'accès aux données (DAL) et donc, j'ai placé l'ensemble dans la dll Data (.edmx / poco / context).

Concernant les MetaData associées aux classes POCO, j'ai l'impression qu'elles rentrent plus dans le cadre d'une logique métier (vérification / contrôle des données) mais aussi dans le cadre de l'affichage. Du coup, j'ai tenté de les définir à plusieurs endroits.

[Nathanael Marchand]

Je confirme effectivement que les POCO ne doivent pas être dans la couche Data mais dans une assembly spécifique qui est une couche transversale (qui remonte de la dal au gui)

[Gat-]

hum Si je comprends bien, je pourrais définir l'archi suivante :

- couche 0, MyProject.Model.dll : contenant le modèle de la base (.edmx) et mes classes POCO.
- couche 1, MyProject.Data.dll : contenant juste mon context qui me permet d'accéder à la base et récupérer des POCO.
- couche 2, MyProject.Core.dll : contenant mes vérif./traitements métiers (que je regrouperai sous forme de services, exemple les classes AccountServices, StatsServices, DocServices, etc) et également des classes "CoreObject" ou "BusinessObject" quasi identiques aux POCO mais auquelles je rattacherai de la logique métier via les MetaData (Required, StringLength et des MetaData personnalisées héritant de ValidationAttribute)
- couche X, MyProject.Resources.dll : contenant autant de fichiers ressources que de langues supportées.
- couche 3, Application (web/win & services) : référençant uniquement Core et utilisant les services et "CoreObject".

Ainsi pour en revenir au projet ASP.NET MVC3, le modèle serait masqué dernière Core et le contrôleur et la vue manipuleraient des "CoreObject".



Pouvez-vous me dire si je m'oriente vers la bonne voie ? Je tente d'adopter de bonnes habitudes en découpant mon application au lieu de mixer le tout et faire un gros pâté immonde...

Mais j'ai vraiment du mal, je découpe n'importe comment, je dois pas raisonner correctement

[Gat-]

arf je comprends plus rien... je viens de lire un article sur developpez.com (ici). Les POCO sont des objets métiers contrairement aux DTO qui ne sont juste que des conteneurs (je pensais qu'ils étaient équivalent )

Donc que ce soit "ADO.NET EntityObject Generator" ou "ADO.NET POCO Entity Generator", ces 2 générateurs génèrent directement à partir du modèle de la base (.edmx) :
- Des classes métiers (EntityObject ou POCO) différent par rapport à l'article car elles contiennent aussi les données.
- Un ObjectContext qui se charge d'accéder aux données (récupération des données, création, mise à jour, suppression) via des ObjectSet.

Du coup, plus besoin de créer une DAL avec des DAO pour chaque table de la base, en utilisant Entity, on ajoute directement la logique métier dans les classes POCO (vérifications/traitements métiers par exemple en ajoutant des MetaData aux propriétés ou en ajoutant des méthodes)

Est-ce exacte cette fois-ci ?