Discussion :

[anthyme]

Bonjour !

Je lance un projet personnel de Framework applicatif, son nom : Arch#

Il s'agit, pour faire court, d'un Framework aidant la création d'application multicouche.

Ca pourrait intéresser ceux qui aime la mise en place d'architecture orienté DDD, EF, l'IoC, la POA ou tout simplement des débutants en architecture.

Un exemple d'objet business utilisant des fonctionnalités du framework :

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
[Order("Title")]
[Includes("Category")]
public class Todo : Entity<int>
{
    [Required]
    [StringLength(50)]
    public virtual string Title { get; set; }
 
    [Required]
    [StringLength(1000)]
    public virtual string Description { get; set; }
 
    [Increment]
    public int Version { get; set; }
 
    [AutoNowCreate]
    public virtual DateTime CreationDate { get; set; }
 
    [AutoNow]
    public virtual DateTime UpdateDate { get; set; }
 
    public virtual Category Category { get; set; }
}

Je vous laisse deviner a quoi servent les Tags

En théorie ces technologies sont indépendantes d'EF et des provider NHibernate et mongoDB vont venir.

Si vous avez envie d'en savoir plus, le projet est ici : http://arch.codeplex.com/ une release avec code source et un petit exemple de développement avec MVC 2 est disponible.

Attention : C#4 et VS 2010 requis

Si vous avez des commentaires ou des idées je suis preneur

A+

[B.AF]

Moi j'aime bien, du code clean, simple et utile.
Si tu veux un coup de main ?

[anthyme]

Bonjour BAf!

Merci pour ton retour sympathique, je suis content que ça plaise

Vis à vis d'un coup de main pourquoi pas, il faut voir sous quel forme ?

Déjà quelques conseils de personnes ayant fait pas mal de boulot d'architecture m'intéresse beaucoup !

Par exemple pour le moment je réfléchis à comment refaire le mécanisme d'interception, je trouve que l'api n'est pas assez bien fait.

Au début c'était plus clean mais il y avait une dépendance forte entre les objets business de l'application utilisant le framework et la DLL Arch.
Ça me gène de partager toute la dll Arch - par exemple - dans un contexte d'application client/serveur partageant le même model objet.
Le problème c'est un peu ça : les objets business ont besoin de connaitre les aspects (Order, Includes, AutoNow, ...) mais ces derniers font pas mal de business et c'est difficile de les découpler d'Arch.
Pour le moment les aspects "Order" et "Includes" se contentent de copier les paramètres (via reflection) dans le repository qui gèrent lui même le comportement résultant de ces aspects.
Donc si tu as des idées d'amélioration en gardant un découplage fort ...

Après je compte créer de nouveaux intercepteurs, notamment pour la validation (avant create et update) utilisant les DataAnnotations et peut être aussi les ValidationAspect
Si quelqu'un as des idées d'autre types d'interception qui pourraient être intéressant je suis prêt à me pencher dessus

Sinon j'ai mis le projet en Alpha pas d'un point de vue où il n'est pas exploitable (j'ai déjà utilisé des mécanismes proches dans des projets réels) mais dans le sens où je compte y ajouter quelques blocs et que l'API risque de bouger encore un peu. Se mettre en mode 1.0 fait perdre de la flexibilité dans les possibilités de modifier le projet et je préfère attendre d'avoir eu quelques retours.

[davcha]

Tu fais un usage intensif de la reflection, non ?

Pour ce qui est de ton mécanisme d'interception, j'ai un projet perso en ce moment qui pourrait te donner quelques pistes intéressantes, et par là même te permettre de te débarrasser de la dépendance à la classe Entity<T>.

Par contre, j'hésite un peu entre diverses architectures pour gérer les types génériques, dans mon projet.

[anthyme]

En effet il y a un peu trop de reflexion à mon gout.

Par exemple le autonow execute cela à chaque update :

Code :

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

1
2
3
4
public void Intercept<T>(T entity, MemberInfo member)
{
    (member as PropertyInfo).GetSetMethod().Invoke(entity, new object[] { DateTime.Now });
}

On pourrait mettre en cache le GetSetMethod ... Sinon (juste) le invoke à partir d'une méthode récupéré via réflexion est plus long qu'un appel standard ?

Ma classe entity n'est pas obligatoire dans mon framework, elle donne juste un "coup de main" sur les GetHashCode, Equals et une propriété "IsTransient".

J'ai réglé mon problème de WCF avec les entity<T> mais si tu as quelque chose d'intéressant pour s'en "débarrasser" je suis pas contre

[davcha]

L'invoke tout court sera plus lent qu'un appel direct, sans reflexion, oui.

Tu peux t'en passer de diverses manières, en fait.
Avec une lambda expression, une méthode dynamique, un proxy dynamique ou carrément en injectant du code dans la méthode interceptée.

Le proxy va t'obliger à te passer d'une instanciation simple avec l'opérateur new.
L'injection de code, ça dépend comment tu t'y prend.

[Bluedeep]

En effet il y a un peu trop de reflexion à mon gout.

Par exemple le autonow execute cela à chaque update :

Code :

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

1
2
3
4
public void Intercept<T>(T entity, MemberInfo member)
{
    (member as PropertyInfo).GetSetMethod().Invoke(entity, new object[] { DateTime.Now });
}

On pourrait mettre en cache le GetSetMethod ... Sinon (juste) le invoke à partir d'une méthode récupéré via réflexion est plus long qu'un appel standard ?

Oui sensiblement. Le mieux dans ce cas est de procéder par injection de code : on utilise la Reflection la première fois, pour déterminer le code à injecter puis on injecte le code (avec "Emit") et ensuite on a des perf normales.