2009-07-27 6 views
0

Nous avons une solution avec deux projets différents, un avec l'exigence qu'il soit fait en utilisant le framework .Net 2.0. L'autre utilise .Net 3.5, et nous suivons MVVM, bien que je soupçonne que c'est moins sur MVVM que de bons motifs.Besoin de suggestions sur une approche à prendre

Le .Net 2.0 a plusieurs objets différents (disons de type Fruit) qui pourraient nécessiter une interface utilisateur WPF différente pour éditer les valeurs de propriété de classe. Pour l'instant, je travaille juste sur le premier. Le projet .net 3.5 est ce que les utilisateurs exécutent et éditent réellement avec. Ma première pensée était que, lorsque nous créons la sous-classe Fruit (Apple, dans le constructeur, il y a un paramètre Func qui retourne l'appel pour créer le dialogue d'édition.) Les autres fruits qui n'ont pas encore été édités avoir un paramètre Func qui renvoie une boîte de dialogue Editeur non supporté.Funcs ne sont pas pris en charge dans 2.0

Ma pensée suivante est, d'ajouter des attributs aux classes .net 2.0 qui se réfèrent aux classes .Net 3.5 qui le projet .net 3.5 pourrait alors créer des instances de, en utilisant la réflexion.Mais cela semble désordonné

Je pourrais créer une classe CreateFruitEditor dans le projet .net 3.5 qui vérifie juste e Le type de fruit et crée la fenêtre d'édition appropriée, mais cela aboutirait finalement à un grand type de vérification de la ligne if (en supposant que les fruits soient très différents lors de l'édition.)

Alors ... Les classes de projet 2.0 doivent en quelque sorte informer mon projet .net 3.5 des classes .net 3.5 à utiliser pour éditer les classes .net 2.0.

Répondre

2

Vous mélangez des problèmes ici. Traitez vos classes .NET 2.0 comme votre modèle et enveloppez-les ou remplacez-les par ViewModels pour vos vues.