İyi mimari ve soyutlama katmanlama kavramlarıyla çelişen C # 'daki async / await kullanım kılavuzları değil mi?

Bu soru C # diliyle ilgilidir, ancak Java veya TypeScript gibi diğer dilleri kapsamasını bekliyorum.

Microsoft , .NET'te zaman uyumsuz çağrıları kullanma konusunda en iyi uygulamaları önerir . Bu tavsiyeler arasında, iki tane seçelim:

• Eşzamansız yöntemlerin imzasını değiştirerek Görev veya Görev <> öğelerini döndürürler (TypeScript'te bir Söz <> olur)
• xxxAsync () ile bitecek async yöntemlerinin adlarını değiştirin

Şimdi, düşük seviyeli, senkronize bir komponenti bir eşzamansız olan ile değiştirirken, bu uygulamanın tam yığınını etkiler. Eşzamansız / beklemede yalnızca "tamamen kullanılırsa" olumlu bir etkiye sahip olduğu için, uygulamadaki her katmanın imzası ve yöntem adlarının değiştirilmesi gerektiği anlamına gelir.

İyi bir mimari çoğu zaman düşük seviyeli bileşenlerin başkaları tarafından değiştirilmesinin üst seviye bileşenler tarafından görülmeyeceği şekilde her bir tabaka arasına soyutlamalar yerleştirmeyi içerir. C # 'da, soyutlamalar arayüz şeklini alır. Yeni, düşük seviyeli, zaman uyumsuz bir bileşen tanıtırsak, çağrı yığınındaki her arabirimin yeni bir arabirimle değiştirilmesi veya değiştirilmesi gerekir. Bir uygulayıcı sınıfta bir problemin çözülme şekli (asenkron veya senkronize) artık arayanlara gizlenmemiş (soyutlanmış). Arayan kişinin senkronize mi, yoksa senkronize mi olmadığını bilmek zorunda.

Async / "iyi mimari" ilkelerine aykırı en iyi uygulamaları beklemiyor musunuz?

Her bir arayüzün (örneğin, IEnumerable, IDataAccessLayer demek) async muadillerine (IAsyncEnumerable, IAsyncDataAccessLayer) ihtiyacı olduğu anlamına gelir mi?

Sorunu biraz daha ileriye götürürsek, her yöntemin eşzamansız olduğunu varsaymak (bir Görev <> veya Söz <> döndürmek) ve gerçekte olmadıklarında eşzamansız çağrıları senkronize etme yöntemleri için daha kolay olmaz mıydı? zaman uyumsuz? Gelecekteki programlama dillerinden beklenen bir şey mi?

İşleviniz Ne Renk?

İlginizi çekebilir Bob Nystrom'un İşlevinizdeki Renk Nedir ¹ .

Bu yazıda, kurgusal bir dili şöyle açıklar:

• Her işlevin bir rengi vardır: mavi veya kırmızı.
• Kırmızı bir işlev mavi veya kırmızı işlevler olarak adlandırılabilir, sorun olmaz.
• Mavi işlev yalnızca mavi işlevleri çağırabilir.

Hayali olsa da, bu programlama dillerinde oldukça düzenli olur:

• C ++ 'da bir "const" yöntemi sadece diğer "const" yöntemlerini çağırabilir this.
• Haskell'de, bir IO olmayan fonksiyon sadece IO olmayan fonksiyonları çağırabilir.
• C # 'da, bir senkronizasyon işlevi yalnızca senkronizasyon işlevlerini ² arayabilir .

Fark ettiğiniz gibi, bu kurallar nedeniyle, kırmızı fonksiyonlar kod tabanının etrafına yayılma eğilimindedir . Bir tane eklersiniz ve yavaş yavaş tüm kod tabanını kolonize eder.

¹ Bob Nystrom, bloglamanın yanı sıra Dart ekibinin bir parçası ve bu küçük Crafting Interpreters serisini yazdı; Herhangi bir programlama dili / derleyici afficionado için şiddetle tavsiye edilir.

² Asenkron bir işlev çağırabildiğiniz ve geri dönene kadar engelleyebileceğiniz için pek doğru değil, ancak ...

Dil Sınırlaması

Bu, esasen, bir dil / çalışma zamanı sınırlamasıdır.

M: Dil, örneğin Erlang ve Go gibi N diş ipliği, asyncfonksiyonlara sahip değildir : her bir fonksiyon potansiyel olarak eşzamansızdır ve "lifi" basitçe askıya alınacak, değiştirilecektir ve tekrar hazır olduğunda geri alınacaktır.

C #, 1: 1 iş parçacığı modeliyle birlikte gitti ve bu nedenle, dişleri yanlışlıkla tıkamaktan kaçınmak için dilde senkronize olmaya karar verdi.

Dil kısıtlamaları varlığında, kodlama yönergeleri uyum sağlamak zorundadır.

Burada haklısın, burada bir çelişki var, ama kötü olan "en iyi uygulamalar" değil. Bunun nedeni asenkron fonksiyonun esas olarak senkron fonksiyondan farklı bir şey yapmasıdır. Sonucu bağımlılıklarından beklemek yerine (genellikle bazı IO) ana olay döngüsü tarafından ele alınacak bir görev yaratır. Bu, soyutlama altında iyi gizlenebilecek bir fark değildir.

Eşzamansız bir yöntem, farkında olduğunuzdan emin olarak eşzamanlı olandan farklı davranır. Çalışma zamanında, zaman uyumsuz bir çağrıyı zaman uyumlu bir çağrıya dönüştürmek önemsizdir, ancak bunun tam tersi söylenemez. Bu nedenle mantık o zaman olur, neden gerektirebilecek her yöntemin asenkron yöntemlerini yapmıyoruz ve arayanı senkronize bir yönteme gerektiği gibi "dönüştürüyor"?

Bir anlamda, istisnaları fırlatan, "güvenli" olan ve hata durumunda bile atmayacak bir metoda sahip olmak gibidir. Kodlayıcı hangi noktada, aksi takdirde bir diğerine dönüştürülebilen bu yöntemleri sağlamak için aşırıdır?

Bu konuda iki düşünce okulu vardır: biri birden çok yöntem oluşturmaktır, her biri diğerine özel yöntem olarak adlandırılır, isteğe bağlı parametreler veya asenkron olma gibi davranışlarda küçük değişiklikler yapma imkanı sunar. Diğeri, gerekli değişiklikleri kendisinin yapması için arayanın üzerine bırakarak gerekli olanları kaldırmak için arayüz yöntemlerini en aza indirmektir.

İlk okuldaysanız, her aramayı iki katına çıkarmaktan kaçınmak için bir sınıfı senkronize ve asenkron aramalara adama konusunda belirli bir mantık vardır. Microsoft, bu düşünce okulunu destekleme eğiliminde ve konvansiyonel olarak Microsoft'un tercih ettiği stille tutarlı kalmak için siz de bir Async sürümüne sahip olmanız gerekecek, tıpkı arayüzlerin neredeyse her zaman "I" ile başlaması gibi. Yanlış olmadığını vurgulamama izin verin , çünkü "doğru yoldan" değil, projede tutarlı bir stil elde etmek ve bir projeye eklediğiniz gelişim için stilinizi kökten değiştirmek daha iyidir.

Bununla birlikte, arayüz yöntemlerini en aza indirgemek olan ikinci okulu tercih etme eğilimindeyim. Bir yöntemin eşzamansız bir şekilde çağrılabileceğini düşünüyorsanız, benim için bu yöntem eşzamansızdır. Arayan, devam etmeden önce bu görevin bitmesini bekleyip beklemeyeceğine karar verebilir. Bu arayüz bir kütüphanenin arayüzü ise, kullanımdan kaldırmanız veya ayarlamanız gereken metot sayısını en aza indirmek için bu şekilde yapmak daha makul olacaktır. Arayüz projemde dahili kullanım içinse, projem boyunca ihtiyaç duyduğum her çağrı için sağlanan parametreler için bir yöntem ekleyeceğim ve "ekstra" yöntem yok, ve o zaman bile, yalnızca yöntemin davranışı zaten kapsanmamışsa mevcut bir yöntemle.

Ancak, bu alandaki birçok şey gibi, büyük ölçüde özneldir. Her iki yaklaşımın da artıları ve eksileri var. Microsoft ayrıca değişken isminin başında tür belirten harfler ekleme ve "m_" gibi bir değişken olduğunu ispatlayan bir sözleşmeye başladı m_pUser. Demek istediğim, Microsoft'un bile yanılmaz olması ve hatalar yapabilmesi.

Bu, eğer projeniz bu Async sözleşmesini izliyorsa, ona saygı duymanızı ve stile devam etmenizi öneririm. Ve sadece bir kez kendinize ait bir proje verildiğinde, uygun gördüğünüz şekilde yazabilirsiniz.

İmzalarını değiştirmeden işlevleri zaman uyumsuz bir şekilde çağırmanın bir yolunun olduğunu hayal edelim.

Bu gerçekten harika olurdu ve hiç kimse isimlerini değiştirmenizi tavsiye etmedi.

Ancak gerçek asenkron fonksiyonlar, sadece başka bir asenkron fonksiyon bekleyenler değil, en düşük seviyenin ise asenkron doğalarına özgü bazı yapıları vardır. Örneğin

public class HTTPClient
{
    public HTTPResponse GET()
    {
        //send data
        while(!timedOut)
        {
            //check for response
            if(response) { 
                this.GotResponse(response); 
            }
            this.YouCanWait();
        }
    }

    //tell calling code that they should watch for this event
    public EventHander GotResponse
    //indicate to calling code that they can go and do something else for a bit
    public EventHander YouCanWait;
}

Bu, kodun, şeylerin hoşuna giden Taskve asynckapsülleyici bir şekilde asenkron bir şekilde çalıştırılması için çağıran kodun ihtiyaç duyduğu iki bilgidir .

Eşzamansız işlev yapmanın birden fazla yolu vardır, async Taskgeri dönüş türleriyle derleyiciye yerleşik tek bir şablondur, böylece olayları el ile bağlamak zorunda kalmazsınız

Ana noktaya daha az C # ness modası ve daha genel bir şekilde değineceğim:

Async / "iyi mimari" ilkelerine aykırı en iyi uygulamaları beklemiyor musunuz?

Bunun sadece API'nizin tasarımında yaptığınız seçime ve kullanıcıya neye izin verdiğinize bağlı olduğunu söyleyebilirim.

API'nizin bir işlevinin yalnızca eşzamansız olmasını istiyorsanız, adlandırma kurallarını izlemeye çok az ilgi vardır. Döndürme türü olarak sadece her zaman Görev <> / Promise <> / Gelecek <> / ... 'ı iade edin, kendi kendini belgelendirir. Senkronize bir cevap istiyorsa, bunu bekleyerek yine de yapabilecektir, ancak her zaman bunu yaparsa, bir miktar kazan yapar.

Ancak, yalnızca API senkronizasyonunuzu yaparsanız, kullanıcı asenkronize etmek isterse asenkron bölümünü kendisi yönetmek zorunda kalacağı anlamına gelir.

Bu oldukça fazladan ek iş yapabilir, ancak aynı zamanda kaç eşzamanlı çağrıya izin verdiği, zaman aşımı, yeniden deneme vb. Durumları konusunda kullanıcıya daha fazla kontrol sağlayabilir.

Büyük bir API'ye sahip büyük bir sistemde, çoğunu varsayılan olarak senkronize etmek üzere uygulamak, özellikle kaynaklarını (dosya sistemi, CPU, veritabanı, ...) paylaşıyorlarsa, API'nizin her bir bölümünü bağımsız olarak yönetmekten daha kolay ve daha verimli olabilir.

Aslında, en karmaşık kısımlar için, API'nizin aynı bölümünün iki uygulamasına mükemmel şekilde sahip olabilirsiniz, biri kullanışlı şeyleri senkronize ederken, biri senkronize olana senkronize olmayan birini kullanıyor, yalnızca eşzamanlılığı, yükleri, zaman aşımlarını ve yeniden denemeleri yönetir .

Belki başkası onunla deneyimlerini paylaşabilir çünkü bu tür sistemlerle ilgili deneyimim yok.