Список <BusinessObject> или BusinessObjectCollection?

это - путь:

возвращаемые массивы, примите IEnumerable<T>

=)

испытайте это:

System.Collections.ObjectModel.Collection<BusinessObject>

это делает ненужным для реализации основного метода как CollectionBase, делают

Я сделал бы это:

using BusinessObjectCollection = List<BusinessObject>;

Это просто создает псевдоним, а не абсолютно новый тип. Я предпочитаю его использованию List< BusinessObject> непосредственно, потому что это оставляет меня свободным изменить глубинную структуру набора в какой-то момент в будущем, не изменяя код, который использует его (как долго, поскольку я обеспечиваю те же свойства и методы).

В большую часть времени я просто иду со Списком путем, поскольку это дает мне всю функциональность, в которой я нуждаюсь в 90% времени, и когда что-то 'дополнительное' необходимо, я наследовался ему, и код что дополнительный бит.

Я склонен делать это со своим собственным набором, если я хочу экранировать доступ к фактическому списку. Когда Вы пишете бизнес-объекты, шанс состоит в том, что Вам нужен рычаг, чтобы знать, добавляется ли Ваш объект/удаляется, в таком смысле я думаю, что BOCollection является лучшей идеей. Из того, потому что если это не требуется, Список более легок. Также Вы могли бы хотеть проверить использование IList для обеспечения дополнительного интерфейса абстракции, если Вам нужно некоторое проксирование (например, поддельный набор инициировал ленивую загрузку из базы данных)

, Но... почему бы не рассмотреть замок ActiveRecord или кто-либо другой назревает платформа ORM?:)

Если Вы принимаете решение создать свой собственный класс набора, необходимо проверить типы в Система. Наборы. Пространство имен .

ObjectModel пространство имен определяет базовые классы, существует ment, чтобы облегчить для лиц, осуществляющих внедрение создавать пользовательские наборы.

6 из 1, полдюжины из другого

Так или иначе это - то же самое. Я только делаю это, когда у меня есть причина добавить пользовательский код в BusinessObjectCollection.

С это имеющий методы загрузки возвращается, список позволяет мне писать, что больше кода в общем универсальном классе и иметь его просто работает. Такой как метод Загрузки.

Я делаю ту же самую вещь как Вы, Jonathan... просто наследовался от List<T>. Вы получаете лучший из обоих миров. Но я вообще только делаю это, когда существует некоторое значение для добавления, как добавление LoadAll() метод или что бы то ни было.

Я использую универсальные списки почти для всех сценариев. Единственное время, когда я рассматривал бы использование полученного набора больше, - то, если я добавляю набор определенные участники. Однако появление LINQ уменьшило потребность в даже этом.

Я вообще только получаю свои собственные классы набора, если я должен "увеличить стоимость". Как, если сам набор должен был иметь некоторые метки свойств "метаданных" наряду с ним.

Необходимо, вероятно, постараться не создавать собственный набор с этой целью. Довольно распространено хотеть изменить тип структуры данных несколько раз во время рефакторингов или при добавлении новых опций. С Вашим подходом Вы волновали бы с отдельным классом для BusinessObjectList, BusinessObjectDictionary, BusinessObjectTree, и т.д.

я действительно не вижу значения в создании этого класса просто, потому что имя класса более читаемо. Да, синтаксис угловой скобки довольно ужасен, но это стандартно в C++, C# и Java, поэтому даже если Вы не пишете код, который использует его, Вы собираетесь столкнуться со всем этим время.

Как кто-то еще указал, рекомендуется не представить Список публично, и FxCop будет хныкать, если Вы сделаете так. Это включает наследование от Списка как в:

public MyTypeCollection : List<MyType>

В большинстве случаев общедоступные API представят IList (или ICollection или IEnumerable) как соответствующий.

В случаях, где Вы хотите свой собственный набор, можно сохранить FxCop тихим путем наследования Набору вместо Списка.

Я шел назад и вперед на 2 опциях:

public class BusinessObjectCollection : List<BusinessObject> {}

или методы, которые просто делают следующее:

public IEnumerable<BusinessObject> GetBusinessObjects();

преимущества первого подхода - то, что можно изменить базовое хранилище данных, не имея необходимость смешивать с сигнатурами методов. К сожалению, если Вы наследовались типу набора, который удаляет метод из предыдущей реализации, тогда необходимо будет справиться с теми ситуациями всюду по коду.

Я предпочитаю только использовать List<BusinessObject>. Typedefing это просто добавляет ненужный шаблон к коду. List<BusinessObject> определенный тип, это не просто никакой List объект, таким образом, это все еще со строгим контролем типов.

, Что еще более важно, объявляя что-то List<BusinessObject> облегчает для всех читающих код для сообщения то, что вводит, они имеют дело с, они не должны искать до фигуры, что BusinessObjectCollection, и затем помните, что это - просто список. typedefing необходимо будет потребовать последовательного (ре) соглашение о присвоении имен, за которым все должны следовать для него, чтобы иметь смысл.

Это , рекомендовал это в общедоступном API не использовать List< T> но использовать Collection< T>

, Если Вы наследовались ему, хотя, необходимо быть в порядке, afaik.

Можно использовать обоих. Для лени - я имею в виду производительность - Список является очень полезным классом, это также "всесторонне" и откровенно полно участников YANGNI. Вместе с разумным аргументом / рекомендация, выдвинутая статья MSDN, уже связанная о представлении Списка как общедоступный участник, я предпочитаю "третий" путь:

Лично я использую шаблон "декоратор" для представления только, в чем я нуждаюсь из Списка т.е.:

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();
    }    
}

Далее все еще я, вероятно, абстрагировал бы OrderItemCollection в IOrderItemCollection, таким образом, я могу подкачать свою реализацию IOrderItemCollection в будущем в (я могу предпочесть использовать другой внутренний счетный объект, такой как Набор, или более вероятный для перфекта используют набор Пары Значения ключа или Набор.

Используйте тип List<BusinessObject>, где необходимо объявить список их. Однако, где Вы возвращаете список BusinessObject, рассматриваете возврат IEnumerable<T>, IList<T> или ReadOnlyCollection<T> - т.е. возвращаете самый слабый контракт, который удовлетворяет клиент.

, Где Вы хотите к тому, "добавляют пользовательский код" к списку, методам расширения кода на типе списка. Снова, присоедините эти методы к самому слабому контракту, например,

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

, Конечно, Вы не можете и не должны добавлять состояние с дополнительными методами, поэтому если необходимо добавить новое свойство и поле позади него, используйте подкласс или лучше, класс обертки для хранения этого.