List czy BusinessObjectCollection?

Jest zalecane aby w publicznym API nie używać List, ale używać Collection

Jeśli jednak dziedziczysz po nim, powinieneś być w porządku, afaik.

Wolę po prostu używać List<BusinessObject>. Wpisując to dodajemy do kodu zbędny boilerplate. List<BusinessObject> jest specyficznym typem, nie jest to zwykły obiekt List, więc nadal jest mocno wpisany.

Co ważniejsze, deklarowanie czegoś List<BusinessObject> ułatwia każdemu czytającemu kod określenie, z jakimi typami ma do czynienia, nie musi przeszukiwać, aby dowiedzieć się, czym jest BusinessObjectCollection, a następnie pamiętać, że to tylko lista. Wpisując, będziesz musiał wymagać spójnego (ponownego)nazewnictwa konwencja, którą każdy musi przestrzegać, aby miała sens.

Użyj typu List<BusinessObject> gdzie musisz zadeklarować ich listę. Jednakże, jeśli zwrócisz listę BusinessObject, rozważ zwrócenie IEnumerable<T>, IList<T> lub ReadOnlyCollection<T> - tj. zwróć najsłabszą możliwą umowę, która zadowoli klienta.

Jeśli chcesz "dodać kod niestandardowy" do listy, koduj metody rozszerzenia w typie listy. Ponownie Dołącz te metody do najsłabszego możliwego kontraktu, np.

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

Oczywiście nie można i nie należy dodawać stanu za pomocą metod extension, więc jeśli trzeba dodać Nowa właściwość i pole za nią, użyj podklasy lub lepszej, klasy wrapper, aby to zapisać.

I ' ve been back and back on 2 options:

public class BusinessObjectCollection : List<BusinessObject> {}

Lub metody, które po prostu wykonują następujące czynności:

public IEnumerable<BusinessObject> GetBusinessObjects();

Korzyści z pierwszego podejścia polega na tym, że można zmienić bazowy magazyn danych bez konieczności bałaganu z podpisami metod. Niestety, jeśli dziedziczysz po typie kolekcji, który usuwa metodę z poprzedniej implementacji, będziesz musiał radzić sobie z tymi sytuacjami w całym kodzie.

Prawdopodobnie powinieneś unikać tworzenia własnej kolekcji w tym celu. Często zdarza się, że podczas refaktoryzacji lub dodawania nowych funkcji kilka razy chcemy zmienić typ struktury danych. Z twoim podejściem skończysz z oddzielną klasą dla BusinessObjectList, BusinessObjectDictionary, BusinessObjectTree itp.

Naprawdę nie widzę żadnej wartości w tworzeniu tej klasy tylko dlatego, że nazwa klasy jest bardziej czytelna. Tak, składnia wspornika kątowego jest trochę brzydka, ale jest to standard w C++, C# i Javie, więc nawet jeśli nie napiszesz kodu, który go używa, będziesz na niego ciągle wpadał.

Robię dokładnie to samo co Ty Jonathan... po prostu Dziedzicz od List<T>. Dostajesz to, co najlepsze z obu światów. Ale generalnie robię to tylko wtedy, gdy jest jakaś wartość do dodania, jak dodanie metody LoadAll() czy cokolwiek innego.

Zazwyczaj wyprowadzam własne klasy kolekcji tylko wtedy, gdy muszę "dodać wartość". Na przykład, jeśli sama kolekcja musi mieć pewne właściwości" metadane " tagowania wraz z nim.

Możesz użyć obu. Dla lenistwa - mam na myśli produktywność-lista jest bardzo przydatną klasą, jest też "obszerna" i szczerze mówiąc pełna członków YANGNI. W połączeniu z sensownym argumentem / rekomendacją przedstawionym przez artykuł MSDN już linkowany o ujawnianiu listy jako członka publicznego, wolę "trzeci" sposób:

Osobiście używam wzoru dekoratora, aby odsłonić tylko to, czego potrzebuję z listy TJ:

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

Dalej jeszcze pewnie bym abstrakcyjny uporządkował IOrderItemCollection więc mogę zamienić moją implementację IOrderItemCollection na w przyszłości w (mogę preferować użycie innego wewnętrznego obiektu enumerable, takiego jak Collection lub bardziej likley dla perf użyj kolekcji pary wartości klucza lub zestawu.

Używam list generycznych dla prawie wszystkich scenariuszy. Jedyny czas, w którym rozważyłbym użycie kolekcji pochodnej, to dodanie konkretnych członków kolekcji. Jednak pojawienie się LINQ zmniejszyło potrzebę nawet tego.

6 of 1, half tuzin of another

Tak czy siak to to samo. Robię to tylko wtedy, gdy mam powód, aby dodać niestandardowy kod do BusinessObjectCollection.

Bez tego, że metody ładowania zwracają listę, pozwala mi napisać więcej kodu we wspólnej klasie generycznej i mieć go po prostu działającego. Takie jak Metoda ładowania.

Jak ktoś inny zauważył, zaleca się nie ujawniać listy publicznie, a FxCop będzie jęczeć, jeśli to zrobisz. Dotyczy to dziedziczenia z listy jak w:

public MyTypeCollection : List<MyType>

W większości przypadków publiczne API ujawniają IList (lub Collection lub IEnumerable) odpowiednio.

W przypadkach, gdy chcesz mieć własną kolekcję niestandardową, możesz zachować FxCop w tajemnicy, dziedzicząc z kolekcji zamiast z listy.

Jeśli zdecydujesz się stworzyć własną klasę kolekcji powinieneś sprawdzić typy w systemie .Kolekcje.ObjectModel Namespace .

Przestrzeń nazw definiuje klasy bazowe, które mają ułatwić implementatorom tworzenie własnych kolekcji.

Zazwyczaj robię to z własną kolekcją, jeśli chcę zabezpieczyć dostęp do rzeczywistej listy. Kiedy piszesz obiekty biznesowe, szansa jest taka, że potrzebujesz Hooka, aby wiedzieć, czy twój obiekt jest dodawany/usuwany, w takim sensie myślę, że BOCollection jest lepszym pomysłem. Bo jeśli nie jest to wymagane, lista jest bardziej lekka. Możesz również sprawdzić użycie IList, aby zapewnić dodatkowy interfejs abstrakcji, jeśli potrzebujesz jakiegoś proxyingu (np. fałszywa kolekcja wyzwala leniwe ładowanie z baza danych)

Ale... dlaczego nie wziąć pod uwagę Castle ActiveRecord lub jakiegokolwiek innego dojrzałego frameworka ORM? :)

W większości przypadków po prostu wybieram sposób listy, ponieważ daje mi ona wszystkie funkcje, których potrzebuję w 90% czasu, a gdy potrzebne jest coś "ekstra", dziedziczę z niego i koduję ten dodatkowy bit.

Zrobiłbym to:

using BusinessObjectCollection = List<BusinessObject>;

To po prostu tworzy alias, a nie zupełnie nowy typ. Wolę używać List bezpośrednio, ponieważ pozostawia mi to swobodę zmiany podstawowej struktury kolekcji w pewnym momencie w przyszłości bez zmiany kodu, który go używa (o ile podam te same właściwości i metody).

Wypróbuj to:

System.Collections.ObjectModel.Collection<BusinessObject>

Nie jest konieczne implementowanie podstawowej metody, takiej jak CollectionBase do

Oto sposób:

Return arrays, accept IEnumerable<T>

=)