Liste<BusinessObject> ou BusinessObjectCollection?

Question

Avant C# génériques, tout le monde serait collections de code pour leur business objects par la création d'une collection de base mis en œuvre IEnumerable

C'est à dire:

public class CollectionBase : IEnumerable

et puis dériverait de leur Entreprise à des collections d'Objets.

public class BusinessObjectCollection : CollectionBase

Maintenant, avec le générique de la liste de classe, personne ne l'utiliser à la place? J'ai trouvé que j'utilise un compromis des deux techniques:

public class BusinessObjectCollection : List<BusinessObject>

Je le fais parce que j'aime avoir fortement typé des noms au lieu de simplement en passant Listes de autour de.

Quelle est votre approche?

Answer 1

Je suis plutôt dans le camp de simplement en utilisant une Liste directement, à moins que pour une raison que j'ai besoin d'encapsuler les données de structure et de fournir un sous-ensemble limité de ses fonctionnalités. C'est principalement parce que si je n'ai pas un besoin spécifique pour l'encapsulation, puis de le faire est juste une perte de temps.

Cependant, avec le total des initialise fonctionnalité de C# 3.0, il ya quelques nouvelles situations où je préconiserais de l'aide personnalisé de la collection de classes.

Fondamentalement, C# 3.0 permet à toute classe qui implémente IEnumerable et a une extension de la méthode à utiliser le nouvel agrégat syntaxe d'initialiseur. Par exemple, parce que le Dictionnaire définit une méthode Add(K key, V valeur), il est possible d'initialiser un dictionnaire à l'aide de cette syntaxe:

var d = new Dictionary<string, int>
{
    {"hello", 0},
    {"the answer to life the universe and everything is:", 42}
};

La grande chose à propos de la fonctionnalité est que cela fonctionne pour ajouter des méthodes avec un nombre quelconque d'arguments. Par exemple, compte tenu de cette collection:

class c1 : IEnumerable
{
    void Add(int x1, int x2, int x3)
    {
        //...
    }

    //...
}

il serait possible de les initialiser comme suit:

var x = new c1
{
    {1,2,3},
    {4,5,6}
}

Cela peut être très utile si vous avez besoin pour créer des tableaux statiques d'objets complexes. Par exemple, si vous utilisiez List<Customer> , et que vous vouliez créer une liste statique des objets de client, vous devez le créer comme ceci:

var x = new List<Customer>
{
    new Customer("Scott Wisniewski", "555-555-5555", "Seattle", "WA"),
    new Customer("John Doe", "555-555-1234", "Los Angeles", "CA"),
    new Customer("Michael Scott", "555-555-8769", "Scranton PA"),
    new Customer("Ali G", "", "Staines", "UK")
}

Toutefois, si vous utilisez une collection personnalisée, comme celui-ci:

class CustomerList  : List<Customer>
{
    public void Add(string name, string phoneNumber, string city, string stateOrCountry)
    {
        Add(new Customer(name, phoneNumber, city, stateOrCounter));
    }
}

Vous pouvez initialiser la collection en utilisant cette syntaxe:

var customers = new CustomerList
{
    {"Scott Wisniewski", "555-555-5555", "Seattle", "WA"},
    {"John Doe", "555-555-1234", "Los Angeles", "CA"},
    {"Michael Scott", "555-555-8769", "Scranton PA"},
    {"Ali G", "", "Staines", "UK"}
}

Ceci a l'avantage d'être à la fois facile et plus facile à lire parce que leur est pas nécessaire de retaper le type d'élément que le nom de chaque élément. L'avantage peut être particulièrement forte si l'élément est de type long ou complexe.

Cela dit, ce n'est utile que si vous avez besoin d'statique des collections de données définies dans votre application. Certains types d'applications, tels que les compilateurs, les utiliser tout le temps. D'autres, comme typique de la base de données des applications n'est pas parce qu'ils chargent l'ensemble de leurs données à partir d'une base de données.

Mon conseil serait que si vous avez besoin de définir une statique de la collection d'objets, ou de la nécessité d'encapsulation à l'écart de la collection de l'interface, puis de créer une classe de collection personnalisée. Sinon, je voudrais juste utiliser List<T> directement.

Answer 2

Il est recommandé que dans les API de ne pas utiliser de Liste<T>, mais pour l'utiliser Collection<T>

Si vous êtes à hériter de ça, cependant, vous devriez être bien, autant que je sache.

Answer 3

Je préfère juste d'utiliser List<BusinessObject>. Typedefing il ajoute juste inutile standard pour le code. List<BusinessObject> est un type spécifique, c'est pas n'importe quel List objet, il est donc encore fortement typé.

Plus important encore, en déclarant quelque chose d' List<BusinessObject> rend plus facile pour tout le monde de lire le code pour indiquer quels types ils sont traiter avec, ils n'ont pas à parcourir par le biais de comprendre ce qu'est un BusinessObjectCollection est et puis n'oubliez pas que c'est juste une liste. Par typedefing, vous devez exiger un uniforme de (re)convention de nommage que tout le monde doit suivre dans l'ordre pour qu'elle ait un sens.

Answer 4

J'ai été un va-et-vient sur les 2 options:

public class BusinessObjectCollection : List<BusinessObject> {}

ou des méthodes qui vient de faire ce qui suit:

public IEnumerable<BusinessObject> GetBusinessObjects();

Les avantages de la première approche est que vous pouvez modifier les données sous-jacentes magasin sans avoir à jouer avec les signatures de méthodes. Malheureusement, si vous héritez d'un type de collection qui supprime une méthode de la mise en œuvre antérieure, alors vous aurez à faire face à ces situations tout au long de votre code.

Answer 5

Utilisez le type List<BusinessObject> où vous devez déclarer une liste d'entre eux. Cependant, lorsque vous retournez une liste d' BusinessObject, envisager de revenir IEnumerable<T>, IList<T> ou ReadOnlyCollection<T> - par exemple le rendement le plus faible possible contrat qui satisfait le client.

Où vous souhaitez ajouter du code personnalisé" à une liste, le code des méthodes d'extension dans la liste type. Encore une fois, fixez ces méthodes pour les plus faibles possibles contrat, par exemple

public static int SomeCount(this IEnumerable<BusinessObject> someList)

Bien sûr, vous ne pouvez pas et ne devez pas ajouter de l'état avec les méthodes d'extension, donc si vous avez besoin d'ajouter une nouvelle propriété et un champ derrière elle, utiliser une sous-classe ou mieux, une classe wrapper pour stocker cette.