Lista o BusinessObjectCollection?

Es recomendado que en las API públicas no se use List, sino Collection

Si usted está heredando de ella sin embargo, usted debe estar bien, afaik.

Prefiero usar solo List<BusinessObject>. Typedefing simplemente agrega repeticiones innecesarias al código. List<BusinessObject> es un tipo específico, no es cualquier objeto List, por lo que todavía está fuertemente escrito.

Más importante aún, declarar algo List<BusinessObject> hace que sea más fácil para todos los que leen el código decir con qué tipos están tratando, no tienen que buscar para averiguar qué es un BusinessObjectCollection y luego recordar que es solo una lista. Por typedefing, tendrás que requerir un (re)nombre consistente convención que todo el mundo tiene que seguir para que tenga sentido.

Use el tipo List<BusinessObject> donde tiene que declarar una lista de ellos. Obstante, cuando devuelva una lista de BusinessObject, considere devolver IEnumerable<T>, IList<T> o ReadOnlyCollection<T> - es decir, devolver el contrato más débil posible que satisfaga al cliente.

Donde desea "agregar código personalizado" a una lista, métodos de extensión de código en el tipo de lista. Una vez más, adjunte estos métodos al contrato más débil posible, por ejemplo,

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

Por supuesto, no puede ni debe agregar estado con métodos de extensión, por lo que si necesita agregar una nueva propiedad y un campo detrás de ella, utilice una subclase o mejor, una clase wrapper para almacenar esto.

He estado yendo y viniendo en 2 opciones:

public class BusinessObjectCollection : List<BusinessObject> {}

O métodos que solo hacen lo siguiente:

public IEnumerable<BusinessObject> GetBusinessObjects();

Los beneficios del primer enfoque es que puede cambiar el almacén de datos subyacente sin tener que interferir con las firmas de los métodos. Desafortunadamente, si heredas de un tipo de colección que elimina un método de la implementación anterior, entonces tendrás que lidiar con esas situaciones a lo largo de tu código.

Probablemente deberías evitar crear tu propia colección para ese propósito. Es bastante común querer cambiar el tipo de estructura de datos unas cuantas veces durante las refactorizaciones o al agregar nuevas características. Con su enfoque, terminaría con una clase separada para BusinessObjectList, BusinessObjectDictionary,BusinessObjectTree, etc.

Realmente no veo ningún valor en la creación de esta clase solo porque el nombre de la clase es más legible. Sí, la sintaxis de los corchetes angulares es un poco fea., pero es estándar en C++, C# y Java, así que incluso si no escribes código que lo use, te encontrarás con él todo el tiempo.

Hago exactamente lo mismo que tú Jonathan... simplemente herede de List<T>. Obtienes lo mejor de ambos mundos. Pero generalmente solo lo hago cuando hay algún valor para agregar, como agregar un método LoadAll() o lo que sea.

Generalmente solo derivo mis propias clases de colección si necesito "agregar valor". Como, si la colección en sí necesitaba tener algunas propiedades de" metadatos " etiquetadas junto con ella.

Puede usar ambos. Para la pereza, me refiero a la productividad, la lista es una clase muy útil, también es "completa" y francamente llena de miembros de YANGNI. Junto con el argumento sensato / recomendación presentada por el artículo de MSDN ya vinculado sobre exponer la Lista como un miembro público, prefiero la "tercera" manera:

Personalmente uso el patrón decorador para exponer solo lo que necesito de la Lista, es decir:

public OrderItemCollection : IEnumerable<OrderItem> 
{
    private readonly List<OrderItem> _orderItems = new List<OrderItem>();

    void Add(OrderItem item)
    {
         _orderItems.Add(item)
    }

    //implement only the list members, which are required from your domain. 
    //ie. sum items, calculate weight etc...

    private IEnumerator<string> Enumerator() {
        return _orderItems.GetEnumerator();
    }

    public IEnumerator<string> GetEnumerator() {
        return Enumerator();
    }    
}

Aún más probablemente abstraería OrderItemCollection en IOrderItemCollection para que pueda cambiar mi implementación de IOrderItemCollection en el futuro en (Puede que prefiera usar un objeto enumerable interno diferente como Collection o más likley para perf use una colección o Conjunto de Pares de Valores Clave.

Utilizo listas genéricas para casi todos los escenarios. La única vez que consideraría usar una colección derivada más es si agrego miembros específicos de la colección. Sin embargo, el advenimiento de LINQ ha disminuido la necesidad de incluso eso.

6 de 1, media docena de otro

De cualquier manera es lo mismo. Solo lo hago cuando tengo razones para agregar código personalizado en BusinessObjectCollection.

Sin que tenga métodos load return, una lista me permite escribir más código en una clase genérica común y hacer que funcione. Como un método de carga.

Como alguien más señaló, se recomienda no exponer la Lista públicamente, y FxCop se quejará si lo hace. Esto incluye heredar de la Lista como en:

public MyTypeCollection : List<MyType>

En la mayoría de los casos, las API públicas expondrán IList (o ICollection oEnumerable) según corresponda.

En los casos en que desee su propia colección personalizada, puede mantener FxCop tranquilo heredando de la Colección en lugar de la Lista.

Si elige crear su propia clase de colección, debe revisar los tipos en el sistema .Colecciones.ObjectModel Namespace .

El espacio de nombres define las clases base para facilitar a los implementadores la creación de colecciones personalizadas.

Tiendo a hacerlo con mi propia colección si quiero proteger el acceso a la lista real. Cuando usted está escribiendo objetos de negocio, la posibilidad es que usted necesita un gancho para saber si su objeto está siendo añadido / eliminado, en tal sentido creo BOCollection es mejor idea. De coz si eso no es necesario, Lista es más ligero. También es posible que desee comprobar el uso de IList para proporcionar una interfaz de abstracción adicional si necesita algún tipo de proxy (por ejemplo, una colección falsa desencadena la carga perezosa de base de datos)

Pero... ¿por qué no considerar Castle ActiveRecord o cualquier otro marco mature maduro? :)

En la mayoría de las veces yo simplemente ir con la Lista, ya que me da toda la funcionalidad que necesito en el 90% del tiempo, y cuando algo 'extra' es necesario, yo herede de ella, y el código extra.

Yo haría esto:

using BusinessObjectCollection = List<BusinessObject>;

Esto simplemente crea un alias en lugar de un tipo completamente nuevo. Prefiero usar List directamente porque me deja libre para cambiar la estructura subyacente de la colección en algún momento en el futuro sin cambiar el código que la usa (siempre y cuando proporcione las mismas propiedades y métodos).

Prueba esto:

System.Collections.ObjectModel.Collection<BusinessObject>

Hace innecesario implementar un método básico como CollectionBase do

Este es el camino:

Devuelve matrices, acepta IEnumerable<T>

=)