2013-01-19 4 views
2

Previous Post removed; Mise à jour:Interface générique w/Polymorphisme pour gérer les objets


J'ai donc une question unique, qui est peut-être assez commun cependant. Les propriétés sont très probablement le code le plus couramment utilisé; car il nécessite que nos données conservent un stockage de valeur constante. J'ai donc pensé comment pourrais-je implémenter ceci? J'ai alors pensé à la facilité avec laquelle Generics peut faire la vie. Malheureusement, nous ne pouvons pas utiliser une propriété dans un générique sans un travail lourd. Donc, voici ma solution/problème; car je ne suis pas sûr que ce soit la meilleure méthode - C'est pourquoi je cherchais un avis de mes pairs. Gardez à l'esprit que l'application sera massive; C'est un exemple très simple.

Résumé:

Présentation couche: L'interface aura une série de champs; ou même des données pour traverser le fil à travers un service web à notre base de données. Donc, ma pensée initiale était une interface qui me permettra de gérer génériquement chacun de mes objets.

// User Interface: 
public class UI : IHolder 
{ 
    void objDetail(List<object> obj) 
    { 
     // Create an Instance 
     List<object> l = new List<object>(); 
     // Add UI Fields: 
     l.Add(Guid.NewGuid()); 
     l.Add(txtFirst.Text); 
     l.Add(txtLast.Text); 
     // l to our obj   
     obj = l; 
     return; 
    } 
} 

Maintenant, j'ai une interface; qui a été utilisé par notre interface utilisateur pour mettre des informations. Maintenant; c'est là que la racine de ma curiosité a été jetée dans le mélange.

// Create an Object Class 
public class Customer : IHolder 
{ 
    // Member Variable: 
    private Guid _Id; 
    private String _First; 
    private String _Last; 

    public Guid Id 
    { 
      get { return _Id; } 
      set { _Id = value; } 
    } 
    public String First 
    { 
      get { return _First; } 
      set { _First = value; } 
    } 
    public String Last 
    { 
      get { return _Last; } 
      set { _Last = value; } 
    } 

    public virtual objDetail(List<Customer> obj) 
    { 
     // Enumerate through List; and assign to Properties. 
    } 
} 

Maintenant c'est où je pensais que ce serait cool; si je pouvais utiliser Polymorphisme pour utiliser la même interface; Mais remplacez-le pour faire la méthode différemment. Donc l'interface utilise un générique; avec la possibilité de Morph à notre classe d'objets donnée.

Maintenant nos classes d'objets; peut se déplacer vers notre interface Entity qui gérera l'opération Crud de base.

Je sais que cet exemple n'est pas le meilleur pour mon intention; comme vous n'avez vraiment pas besoin d'utiliser le polymorphisme. Mais, cela est l'idée générale/but ...

  • Interface stocker Présentation couche UI Champ Valeur
  • Mettre en œuvre les propriétés à une classe souhaitée
  • Créer un wrapper autour de ma classe; qui peut être polymorphisé.
  • Morphed à un générique pour Crud Opération

Suis-je sur la bonne voie; est-ce tabou? Est-ce que je ne devrais pas faire ça? Mon application doit contenir chaque instance; mais j'ai besoin de la flexibilité pour m'adapter très rapidement sans casser chaque instance dans le processus. C'est ainsi que j'ai pensé pouvoir résoudre le problème. Des pensées? Suggestions? Ai-je manqué un concept ici? Ou suis-je trop penser? Est-ce que j'ai manqué le bateau et mis en application mon idée complètement faux? C'est là que je suis perdu ...

+2

Votre classe Customer ne semble pas implémenter ICustomer et votre interface IEntity semble plus appropriée pour une collection qu'une seule entité. Peut-être besoin de clarifier votre question et vos exemples. –

+0

Était pressé mais je suis d'accord. Pensé à la façon de mettre en œuvre cela pour la plupart de la journée – Greg

Répondre

0

Après avoir réfléchi un peu à ce scénario, j'ai pensé à ce qui fournirait cette flexibilité tout en assurant que le code est optimisé pour la modification et les affaires. Je ne suis pas sûr que ce soit la bonne solution, mais cela semble fonctionner. Non seulement ça marche, mais ça marche bien. Il semble être assez robuste.

Quand cette approche est-elle utile?Eh bien, lorsque vous avez l'intention de découpler votre interface utilisateur de votre logique. Je vais progressivement construire chaque aspect afin que vous puissiez voir toute la structure.

public interface IObjContainer<T> 
{ 
    void container(List<T> object); 
} 

Cette structure particulière sera importante. Comme il va stocker tout le contenu souhaité en elle. Donc, pour commencer, vous créez un formulaire avec une série de champs.

  • Informations personnelles
  • Adresse Informations
  • Informations de paiement
  • Informations sur la commande

Comme vous pouvez le voir tous ces éléments peuvent être les tableaux de bases de données distinctes, mais appartiennent à un modèle similaire de l'entité vous manipulez. C'est assez commun.

Donc, une ségrégation de préoccupation commencera à montrer légèrement, les champs seront manipulés et passés à travers une interface. Donc, essentiellement, l'interface passe sa variable à l'interface. Ainsi, vous obtiendrez une interface pour gérer tout le formulaire ou les interfaces individuelles que vous souhaitez appeler afin qu'ils restent réutilisables.

Alors maintenant vous avez une série d'Interfaces, ou une seule fois. Mais il contient toutes ces variables à utiliser. Donc, vous maintenant créer une classe:

public class CustomerProperties: IPersonalInformation, IOrderInformation 
{ 
    // Implement each Interface Property 
} 

Maintenant que vous avez créé un conteneur qui contiendra toutes vos valeurs. Ce qui est intéressant avec ce conteneur, c'est que vous pouvez réutiliser les mêmes valeurs pour une autre classe dans votre application ou en choisir d'autres. Mais il va logiquement séparer l'interface utilisateur.

Donc, essentiellement, cela ressemble à un référentiel.

Maintenant vous pouvez prendre ces valeurs et effectuer la logique désirée. Ce qui devient merveilleux maintenant, c'est qu'après avoir exécuté votre logique, vous passez l'objet dans notre liste générique. Ensuite, vous implémentez simplement cette méthode dans une autre classe pour votre objectif et parcourez votre liste.

L'honnêteté est qu'il semble bien fonctionner et se découpler bien. Je pense qu'il a fallu beaucoup de travail pour faire quelque chose de similaire à un référentiel normal et une unité de travail, cela répond à la question mais la météo ou non c'est idéal pour votre projet je regarderais dans Repository, Unit Of Work, Segregation Of Concern, Inversion de contrôle et Injection de dépendances. Ils peuvent faire ce même nettoyeur d'approche.


Mise à jour:

Je pensais à ce sujet après avoir écrit ce, je remarque que vous pouvez réellement mettre en œuvre ces valeurs de propriété dans la structure Liste générique sans passer par une série d'interfaces; mais cela poserait des problèmes de cohérence car il faudrait savoir quelles données sont transmises à chaque fois, dans l'ordre. C'est possible, mais peut-être pas idéal.

Questions connexes