Comment faire en sorte que le DataBinder / SmartDispatcherController de Castle MonoRail soit lié à des types contenant des propriétés qui sont des interfaces?

Question

Nous utilisons des interfaces pour représenter les classes d'entités dans notre modèle de domaine. Nous avons des implémentations concrètes de ceux-ci grâce à LinqToSql. Nous avons ajouté une méthode de fabrique à chaque classe LinqToSql utilisée par notre couche service pour instancier une nouvelle entité (remarque; contrairement à l'attribut DataBind du contrôleur).

L'implémentation DataBinder par défaut de MonoRail ignorera les propriétés définies comme interfaces.

Idéalement, nous ne souhaitons pas instancier nos classes de couche de données dans MonoRail - le point essentiel des interfaces est de séparer ces préoccupations.

De plus, nous ne souhaitons pas vraiment créer un autre ensemble de classes concrètes autres que LinqToSql dont le seul travail est de traduire entre des couches.

C’est la fin d’une vraiment journée longue ici; s'il vous plaît, quelqu'un peut-il avoir pitié de nous et nous indiquer les parties d'IDataBinder que nous devrions surcharger avec nos propres implémentations ou suggérer d'autres approches que nous pourrions essayer? ; -)

Answer 1

Vous devriez regarder IParameterBinder. jetez un oeil à un article que j'ai écrit sur le sujet

Answer 2

Comme Ken l'a souligné, votre idée pourrait être mise en œuvre avec un IParameterBinder personnalisé.

Une solution serait d'utiliser IOC:

• résoudre une instance concrète du formulaire à partir de son interface
• utilisez ensuite IDataBinder pour lier l’instance aux paramètres de la demande

Un autre utilisera IDictionaryAdapter:

• générer un proxy dto pour votre interface
• utilisez ensuite IDataBinder pour lier l’instance de proxy dto aux paramètres de la demande

NB: la deuxième option ne fonctionnera pas si l'interface:

• n'est pas public (hum)
• a des méthodes
• ou des événements
• ou propriétés en lecture seule
• ou setonly properties

Enfin, je ne sais pas quel est le problème qui expose une classe concrète dans la signature du contrôleur.

J'utilise moi-même une forme concrète dans les contrôleurs implémentant l'interface définie dans les services de la couche application, cela me permet de séparer les problèmes des deux côtés:

• le côté contrôleur est le mappage Http et la validation des données de premier niveau du formulaire / commande
• services de couche application est la validation commerciale et le traitement du formulaire / commande