IList <T> yerine her zaman IEnumerable <T> döndürmeli miyim?

DAL'ımı veya bir dizi öğe döndüren başka bir kodu yazarken, her zaman return ifademi yapmalı mıyım:

public IEnumerable<FooBar> GetRecentItems()

veya

public IList<FooBar> GetRecentItems()

Şu anda, kodumda IEnumerable'ı olabildiğince kullanmaya çalışıyorum, ancak bunun en iyi uygulama olup olmadığından emin değilim? Doğru görünüyordu çünkü en genel veri türünü döndürürken hala ne yaptığını açıklıyordum, ama belki de bunu yapmak doğru değil.

Gerçekten neden bu belirli arayüzü kullandığınıza bağlı.

Örneğin, IList<T>içinde bulunmayan birkaç yöntemi vardır IEnumerable<T>:

• IndexOf(T item)
• Insert(int index, T item)
• RemoveAt(int index)

ve Özellikler:

• T this[int index] { get; set; }

Bu yöntemlere herhangi bir şekilde ihtiyacınız varsa, o zaman elbette geri dönün IList<T>.

Ayrıca, IEnumerable<T>sonucunuzu tüketen yöntem bir bekliyorsa IList<T>, CLR'yi gereken dönüştürmeleri dikkate almaktan kurtaracak ve böylece derlenen kodu optimize edecektir.

Çerçeve tasarım yönergeleri , arayan tarafından değiştirilebilen bir koleksiyon veya salt okunur koleksiyonlar için ReadOnlyCollection döndürmeniz gerektiğinde Collection sınıfını kullanmanızı önerir .

Bu bir basit tercih edilir nedeni IListolduğunu IListonun sadece ya da değil okursanız arayan bilgilendirmek etmez.

IEnumerable<T>Bunun yerine bir döndürürseniz , arayanın gerçekleştirmesi için bazı işlemler biraz daha yanıltıcı olabilir. Ayrıca arayan kişiye, isteyebileceğiniz veya istemeyebileceğiniz bir şeyi, koleksiyonu değiştirme esnekliği de vermeyeceksiniz.

LINQ'nun birkaç numara içerdiğini ve belirli çağrıları gerçekleştirildikleri türe göre optimize edeceğini unutmayın. Bu nedenle, örneğin, bir gerçekleştirirseniz Countve temel alınan koleksiyon bir Liste ise, tüm öğelerin üzerinden YÜRÜMEZ.

Kişisel olarak, bir ORM için muhtemelen Collection<T>dönüş değerim olarak bağlı kalırım .

Genel olarak, en genel olanı talep etmeli ve yapabileceğiniz en spesifik şeyi iade etmelisiniz. Dolayısıyla, bir parametre alan bir yönteminiz varsa ve yalnızca IEnumerable'da mevcut olana gerçekten ihtiyacınız varsa, bu sizin parametre türünüz olmalıdır. Yönteminiz bir IList veya bir IEnumerable döndürebiliyorsa, IList döndürmeyi tercih edin. Bu, en geniş tüketici yelpazesi tarafından kullanılabilmesini sağlar.

İhtiyaç duyduğunuz şeyde gevşek olun ve sağladığınız şeyde açık olun.

Bu bağlıdır...

En az türetilmiş türü ( IEnumerable) döndürmek, altta yatan uygulamayı yolun aşağısında değiştirmek için size en fazla alan bırakır.

Daha türetilmiş bir tür ( IList) döndürmek, API'nizin kullanıcılarına sonuç üzerinde daha fazla işlem sağlar.

Her zaman, kullanıcılarınızın ihtiyaç duyacağı tüm işlemlere sahip en az türetilmiş türü döndürmenizi öneririm ... Bu nedenle, temel olarak, ilk olarak, tanımladığınız API bağlamında sonuç üzerindeki hangi işlemlerin anlamlı olduğunu anlamanız gerekir.

Dikkate alınması gereken bir nokta , kendi yönteminizi oluşturmak için ertelenmiş bir yürütme LINQ deyimi kullanıyorsanız , yönteminizden dönmeden önce IEnumerable<T>arama yapmak .ToList(), öğelerinizin iki kez yinelenebileceği anlamına gelir - biri Listeyi oluşturmak için ve biri de arayan dönüş değerinizi filtreler veya dönüştürür. Pratik olduğunda, gerekene kadar LINQ-to-Objects sonuçlarını somut bir Listeye veya Sözlüğe dönüştürmekten kaçınmayı seviyorum. Arayanın bir Listeye ihtiyacı varsa, bu tek bir kolay yöntem aramasıdır - onlar için bu kararı vermeme gerek yok ve bu, arayanın sadece bir foreach yaptığı durumlarda kodumu biraz daha verimli hale getirir.

List<T>çağıran kodu, döndürülen nesneyi değiştirme ve dizine göre erişim gibi birçok özellik sunar. Öyleyse soru şu şekildedir: uygulamanızın özel kullanım durumunda, bu tür kullanımları (muhtemelen yeni oluşturulmuş bir koleksiyon geri göndererek!), Arayanın rahatlığı için desteklemek İSTER MİSİNİZ - yoksa basit durum için hız ister misiniz? Arayan kişinin ihtiyacı koleksiyon boyunca döngü içinde olmak ve bunun yanlış bir şekilde değiştirilmesine neden olacağından korkmadan gerçek bir temel koleksiyona bir referansı güvenli bir şekilde iade edebilirsiniz.

Bu soruyu yalnızca siz cevaplayabilirsiniz ve yalnızca arayanlarınızın geri dönüş değeri ile ne yapmak isteyeceğini ve burada performansın ne kadar önemli olduğunu (koleksiyonlarınız ne kadar büyük kopyalarsınız, bunun bir darboğaz olma olasılığı ne kadar? vb).

Bence ikisini de kullanabilirsin, ama her birinin bir faydası var. Temelde öyledir List, IEnumerableancak sayma işlevine sahipsiniz, öğe ekleyin, öğeyi kaldırın

IEnumerable, öğeleri saymak için verimli değil

Koleksiyonun salt okunur olması amaçlanıyorsa veya koleksiyonun modifikasyonu tarafından kontrol ediliyorsa, Parentbir IListjust for döndürmek Countiyi bir fikir değildir.

Linq'te, CLR'nin içinde temeldeki türün olup olmadığına kısayol olacağı bir Count()genişletme yöntemi vardır , bu nedenle performans farkı ihmal edilebilir.IEnumerable<T>.CountIList

Genel olarak, mümkün olduğunda IEnumerable'ı iade etmenin daha iyi bir uygulama olduğunu düşünüyorum (görüş), eğer eklemeler yapmanız gerekiyorsa, daha sonra bu yöntemleri ana sınıfa ekleyin, aksi takdirde tüketici, Model içindeki koleksiyonu yönetiyor ve bu da ilkeleri manufacturer.Models.Add(model)ihlal ediyor , örn . demeter. Elbette bunlar sadece yönergelerdir ve zor ve hızlı kurallar değildir, ancak uygulanabilirliği tam olarak kavrayana kadar, körü körüne takip etmek, hiç takip etmekten iyidir.

public interface IManufacturer 
{
     IEnumerable<Model> Models {get;}
     void AddModel(Model model);
}

(Not: nNHibernate kullanıyorsanız, farklı erişimciler kullanarak özel IList ile eşlemeniz gerekebilir.)

Girdi parametreleri yerine dönüş değerlerinden bahsederken bu o kadar basit değildir. Bir girdi parametresi olduğunda, tam olarak ne yapmanız gerektiğini bilirsiniz. Dolayısıyla, koleksiyon üzerinde yineleme yapabilmeniz gerekiyorsa, bir IEnumberable alırsınız, ancak eklemeniz veya kaldırmanız gerekirse, bir IList alırsınız.

Bir dönüş değeri durumunda, daha zordur. Arayanınız ne bekliyor? Bir IEnumerable döndürürseniz, o zaman bundan bir IList çıkarabileceğini önceden bilemeyecektir. Ancak, bir IList döndürürseniz, üzerinde yineleme yapabileceğini bilecektir. Bu nedenle, arayan kişinin verilerle ne yapacağını hesaba katmalısınız. Arayanınızın ihtiyaç duyduğu / beklediği işlevsellik, neyin iade edileceğine karar verirken neyin yönetmesi gerektiğidir.

hepsinin söylediği gibi, katmanı çağırırken Add / Remove functioanlity istemiyorsanız, IEnumerable'a oy vereceğim, çünkü tasarım açısından sevdiğim gibi sadece yineleme ve temel işlevsellik sağlıyor. Geri dönen IList oylarım her zaman yeniden öneriyor ama esas olarak ne sevip ne sevmiyorsunuz. performans açısından daha çok aynı olduklarını düşünüyorum.

Harici kodunuzda saymazsanız, IEnumerable'ı döndürmek her zaman daha iyidir, çünkü daha sonra uygulamanızı değiştirebilir (harici kod etkisi olmadan), örneğin yineleyici mantığı elde etmek ve bellek kaynaklarını korumak için (bu arada çok iyi dil özelliği) ).

Ancak, öğe sayısına ihtiyacınız varsa, IEnumerable ile IList - ICollection arasında başka bir katman olduğunu unutmayın .

Şimdiye kadar kimsenin önermediğini görünce burada biraz uzakta olabilirim, ama neden bir dönmüyorsun (I)Collection<T>?

Hatırladığım kadarıyla, uygulamayı soyutladığı Collection<T>için tercih edilen dönüş türü oldu List<T>. Hepsi uyguluyor IEnumerable, ama bu bana iş için biraz fazla düşük seviyede geliyor.

Bence ikisini de kullanabilirsin, ama her birinin bir faydası var. Temelde öyledir List, IEnumerableancak sayma işlevine sahipsiniz, Öğe ekle, öğe kaldır

IEnumerable öğeleri saymak veya koleksiyondaki belirli bir öğeyi almak için verimli değildir.

List belirli öğeleri bulmak, öğeleri eklemek veya kaldırmak için ideal olan bir koleksiyondur.

Genelde Listmümkün olduğunca kullanmaya çalışıyorum çünkü bu bana daha fazla esneklik sağlıyor.

Kullanım List<FooBar> getRecentItems() yerine IList<FooBar> GetRecentItems()

Bence genel kural, gereksiz işleri yapmaktan kaçınmak ve arayan kişiye daha fazla seçenek vermek için geri dönmek için daha spesifik sınıfı kullanmaktır.

Bununla birlikte, yazdığınız kodu önünüzde düşünmenin, bir sonraki kişinin yazacağı koddan daha önemli olduğunu düşünüyorum (mantık çerçevesinde.) Bunun nedeni, zaten var olan kod hakkında varsayımlarda bulunabilmenizdir.

Bir arabirimde IEnumerable'dan bir koleksiyona UP hareketinin işe yarayacağını, bir koleksiyondan IEnumerable'a geçişin mevcut kodu bozacağını unutmayın.

Bu görüşler çelişkili görünüyorsa, bunun nedeni kararın öznel olmasıdır.

TL; DR; - özet

• Şirket içi yazılım geliştiriyorsanız List, koleksiyonlar durumunda bile dönüş değerleri için belirli türü (Like ) ve girdi parametreleri için en genel türü kullanın.
• Bir yöntem yeniden dağıtılabilir kitaplığın genel API'sinin bir parçasıysa, hem dönüş değerlerini hem de girdi parametrelerini tanıtmak için somut koleksiyon türleri yerine arabirimler kullanın.
• Bir yöntem salt okunur bir koleksiyon döndürürse, bunu dönüş değeri türü olarak IReadOnlyListveya kullanarak gösterin IReadOnlyCollection.

Daha