แนวทางของ async / ไม่ใช้งานการรอคอยใน C # ขัดแย้งกับแนวคิดของสถาปัตยกรรมที่ดีและการฝังรากลึกนามธรรม?

คำถามนี้เกี่ยวกับภาษา C # แต่ฉันคาดหวังให้ครอบคลุมภาษาอื่นเช่น Java หรือ TypeScript

Microsoft แนะนำแนวทางปฏิบัติที่ดีที่สุดในการใช้การโทรแบบอะซิงโครนัสใน. NET ในบรรดาคำแนะนำเหล่านี้เรามาเลือกสองข้อ:

• เปลี่ยนลายเซ็นของเมธอด async เพื่อให้ส่งคืนงานหรืองาน <> (ใน TypeScript นั่นจะเป็นสัญญา <>)
• เปลี่ยนชื่อของวิธีการ async เป็นลงท้ายด้วย xxxAsync ()

ตอนนี้เมื่อแทนที่ส่วนประกอบที่มีระดับต่ำและซิงโครนัสด้วยอะซิงก์หนึ่งสิ่งนี้จะส่งผลกระทบต่อสแต็กเต็มของแอปพลิเคชัน เนื่องจาก async / await มีผลกระทบเชิงบวกต่อเมื่อใช้ "all-up up" เท่านั้นนั่นหมายถึงชื่อลายเซ็นและเมธอดของทุกเลเยอร์ในแอปพลิเคชันจะต้องเปลี่ยน

สถาปัตยกรรมที่ดีมักจะเกี่ยวข้องกับการวาง abstractions ระหว่างแต่ละเลเยอร์เช่นการแทนที่ส่วนประกอบระดับต่ำโดยผู้อื่นจะมองไม่เห็นโดยส่วนประกอบระดับบน ใน C # abstractions จะอยู่ในรูปของอินเตอร์เฟส หากเราแนะนำส่วนประกอบ async ใหม่ระดับต่ำและต่ำแต่ละอินเตอร์เฟสใน call stack จำเป็นต้องได้รับการแก้ไขหรือแทนที่ด้วยอินเตอร์เฟสใหม่ วิธีการแก้ไขปัญหา (async หรือ sync) ในชั้นเรียนการใช้งานจะไม่ถูกซ่อน (abstracted) กับผู้โทรอีกต่อไป ผู้โทรต้องทราบว่าซิงค์หรือไม่

async / รอปฏิบัติที่ดีที่สุดไม่ตรงข้ามกับหลักการ "สถาปัตยกรรมที่ดี" หรือไม่?

หมายความว่าแต่ละอินเทอร์เฟซ (พูดว่า IEnumerable, IDataAccessLayer) จำเป็นต้องมีการซิงค์แบบอะซิงโครนัส (IAsyncEnumerable, IAsyncDataAccessLayer) เพื่อให้สามารถแทนที่ในสแต็กเมื่อสลับเป็นการพึ่งพาแบบอะซิงโครนัส

หากเราผลักดันปัญหาไปอีกสักหน่อยคงไม่เป็นการง่ายกว่าที่จะสมมติว่าทุกวิธีเป็นแบบซิงค์ (เพื่อส่งคืนภารกิจ <> หรือสัญญา <>) และสำหรับวิธีการซิงโครไนซ์การโทรแบบอะซิงโครไนซ์เมื่อไม่จริง async? นี่เป็นสิ่งที่คาดหวังจากภาษาการเขียนโปรแกรมในอนาคตหรือไม่

ฟังก์ชั่นของคุณสีอะไร?

คุณอาจจะสนใจในบ๊อบ Nystrom ของสีคืออะไรฟังก์ชั่นของคุณ 1

ในบทความนี้เขาอธิบายภาษาสมมติที่:

• แต่ละฟังก์ชั่นมีสี: สีน้ำเงินหรือสีแดง
• ฟังก์ชั่นสีแดงอาจเรียกใช้ฟังก์ชั่นสีน้ำเงินหรือสีแดงไม่มีปัญหา
• ฟังก์ชั่นสีน้ำเงินอาจเรียกฟังก์ชั่นสีน้ำเงินเท่านั้น

ในขณะที่สมมติขึ้นสิ่งนี้เกิดขึ้นค่อนข้างสม่ำเสมอในภาษาการเขียนโปรแกรม:

• ใน C ++ เมธอด "const" อาจเรียกเมธอด "const" thisอื่นเท่านั้น
• ใน Haskell ฟังก์ชันที่ไม่ใช่ IO อาจเรียกใช้ฟังก์ชันที่ไม่ใช่ IO เท่านั้น
• ใน C # ฟังก์ชั่นการซิงค์อาจเรียกใช้ฟังก์ชั่นการซิงค์²เท่านั้น

ดังที่คุณทราบเนื่องจากกฎเหล่านี้ฟังก์ชั่นสีแดงมักจะแพร่กระจายไปทั่วฐานรหัส คุณแทรกหนึ่งและทีละน้อยมันอาณานิคมฐานรหัสทั้งหมด

¹ Bob Nystrom นอกเหนือจากบล็อกแล้วยังเป็นส่วนหนึ่งของทีม Dart และได้เขียนเซเรียอาคราฟต์ตัวน้อยนี้ แนะนำเป็นอย่างยิ่งสำหรับภาษาการเขียนโปรแกรม / afficionado ใด ๆ

² ไม่จริงอย่างที่คุณอาจเรียกใช้ฟังก์ชัน async และบล็อกจนกว่ามันจะกลับมา แต่ ...

ข้อ จำกัด ทางภาษา

นี่คือข้อ จำกัด ทางภาษา / เวลาทำงาน

ภาษาที่มี M: N เธรดตัวอย่างเช่น Erlang และ Go ไม่มีasyncฟังก์ชั่น: แต่ละฟังก์ชั่นอาจเป็นแบบอะซิงก์และ "ไฟเบอร์" ของมันจะถูกระงับชั่วคราวสลับและสลับกลับมาเมื่อพร้อมอีกครั้ง

C # ไปกับโมเดลการทำเกลียว 1: 1 และดังนั้นจึงตัดสินใจที่จะซิงโครไนซ์ในภาษาเพื่อหลีกเลี่ยงการบล็อกเธรดโดยไม่ตั้งใจ

เมื่อมีข้อ จำกัด ด้านภาษาแนวทางการเข้ารหัสต้องปรับเปลี่ยน

คุณอยู่ที่นั่นมีความขัดแย้งที่นี่ แต่ไม่ใช่ "การปฏิบัติที่ดีที่สุด" ที่ไม่ดี เป็นเพราะฟังก์ชั่นอะซิงโครนัสทำสิ่งที่แตกต่างจากซิงโครนัส แทนที่จะรอผลลัพธ์จากการขึ้นต่อกันของมัน (โดยปกติจะเป็น IO บางส่วน) มันสร้างงานที่ต้องจัดการโดยเหตุการณ์หลักของลูป นี่ไม่ใช่ความแตกต่างที่สามารถซ่อนตัวได้ดีภายใต้สิ่งที่เป็นนามธรรม

วิธีการแบบอะซิงโครนัสทำงานแตกต่างจากวิธีการแบบซิงโครนัสซึ่งฉันแน่ใจว่าคุณทราบแล้ว ที่รันไทม์การแปลงการโทรแบบ async เป็นแบบซิงโครนัสเป็นเรื่องเล็กน้อย แต่ไม่สามารถพูดสิ่งที่ตรงกันข้ามได้ ดังนั้นตรรกะจึงกลายเป็นทำไมเราไม่ทำวิธีการ async ของทุกวิธีที่อาจต้องใช้มันและให้ผู้โทร "แปลง" ตามที่จำเป็นในวิธีการซิงโครนัส?

ในความรู้สึกมันก็เหมือนมีวิธีการที่โยนข้อยกเว้นและอื่น ๆ ที่ "ปลอดภัย" และจะไม่โยนแม้ในกรณีที่มีข้อผิดพลาด coder มีมากเกินไปที่จุดใดเพื่อให้วิธีการเหล่านี้ซึ่งมิฉะนั้นสามารถแปลงหนึ่งไปยังอีก?

ในเรื่องนี้มีโรงเรียนแห่งความคิดสองแห่ง: หนึ่งคือการสร้างหลายวิธีแต่ละคนเรียกอีกวิธีส่วนตัวอาจอนุญาตให้มีความเป็นไปได้ของการให้พารามิเตอร์ทางเลือกหรือการปรับเปลี่ยนเล็กน้อยกับพฤติกรรมเช่นการไม่ตรงกัน อีกวิธีหนึ่งคือลดวิธีการอินเทอร์เฟซให้กับข้อมูลสำคัญที่ไม่จำเป็นโดยปล่อยให้ผู้โทรดำเนินการแก้ไขที่จำเป็นด้วยตนเอง

หากคุณอยู่ในโรงเรียนแห่งแรกมีตรรกะบางอย่างที่จะอุทิศชั้นเรียนเพื่อการโทรแบบซิงโครนัสและอะซิงโครนัสเพื่อหลีกเลี่ยงการโทรทุกครั้งเป็นสองเท่า Microsoft มีแนวโน้มที่จะสนับสนุนโรงเรียนแห่งความคิดนี้และโดยการประชุมเพื่อให้สอดคล้องกับสไตล์ที่ Microsoft โปรดปรานคุณก็จะต้องมีเวอร์ชัน Async ด้วยวิธีเดียวกันกับที่อินเตอร์เฟสมักจะเริ่มต้นด้วย "I" ฉันขอย้ำว่ามันไม่ผิดเลยเพราะมันเป็นการดีกว่าที่จะรักษาสไตล์ที่สอดคล้องกันในโครงการแทนที่จะทำ "วิธีที่ถูกต้อง" และเปลี่ยนสไตล์การพัฒนาที่คุณเพิ่มเข้าไปในโครงการอย่างสิ้นเชิง

ที่กล่าวว่าฉันมักจะชอบโรงเรียนที่สองซึ่งจะลดวิธีการอินเตอร์เฟซ ถ้าฉันคิดว่าวิธีการอาจถูกเรียกในลักษณะอะซิงโครนัสวิธีสำหรับฉันคือไม่ตรงกัน ผู้เรียกสามารถตัดสินใจว่าจะรอให้ภารกิจนั้นเสร็จสิ้นก่อนที่จะดำเนินการต่อหรือไม่ หากอินเทอร์เฟซนี้เป็นอินเทอร์เฟซไปยังไลบรารีมีเหตุผลมากกว่าที่จะทำเช่นนี้เพื่อลดจำนวนวิธีที่คุณต้องการลดค่าใช้จ่ายหรือปรับเปลี่ยน หากอินเทอร์เฟซสำหรับการใช้งานภายในในโครงการของฉันฉันจะเพิ่มวิธีการสำหรับการโทรทุกครั้งที่จำเป็นสำหรับโครงการของฉันสำหรับพารามิเตอร์ที่ให้ไว้และไม่มีวิธี "พิเศษ" และแม้กระทั่งถ้าพฤติกรรมของวิธีการไม่ครอบคลุม โดยวิธีการที่มีอยู่

อย่างไรก็ตามเช่นเดียวกับหลายสิ่งในสาขานี้มันเป็นเรื่องส่วนตัว ทั้งสองวิธีมีข้อดีข้อเสีย ไมโครซอฟท์ก็เริ่มการประชุมของการเพิ่มตัวอักษรที่บ่งบอกถึงประเภทที่จุดเริ่มต้นของชื่อตัวแปรและ "m_" m_pUserเพื่อแสดงว่าเป็นสมาชิกคนหนึ่งที่นำไปสู่ชื่อตัวแปรเช่น ประเด็นของฉันคือแม้กระทั่ง Microsoft ก็ไม่ผิดพลาดและสามารถทำผิดพลาดได้เช่นกัน

ที่กล่าวว่าหากโครงการของคุณปฏิบัติตามอนุสัญญา Async นี้ฉันขอแนะนำให้คุณเคารพมันและดำเนินการตามสไตล์ต่อไป และเมื่อคุณได้รับโครงการของคุณเองแล้วคุณสามารถเขียนมันออกมาในแบบที่ดีที่สุดที่คุณเห็นว่าเหมาะสม

ลองนึกภาพว่ามีวิธีที่จะทำให้คุณสามารถเรียกใช้ฟังก์ชั่นแบบ async ได้โดยไม่ต้องเปลี่ยนลายเซ็น

นั่นจะเจ๋งจริงๆและไม่มีใครแนะนำให้คุณเปลี่ยนชื่อ

แต่ฟังก์ชั่นอะซิงโครนัสที่เกิดขึ้นจริงไม่ใช่แค่ฟังก์ชั่นที่รอฟังก์ชั่นอะซิงก์อีกตัว แต่ระดับต่ำสุดมีโครงสร้างบางอย่างที่เฉพาะเจาะจงกับลักษณะอะซิงก์ เช่น

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

เป็นข้อมูลสองบิตที่รหัสการโทรต้องการเพื่อเรียกใช้รหัสในแบบอะซิงก์ที่สิ่งต่าง ๆ เช่นTaskและasyncแค็ปซูล

มีมากกว่าหนึ่งวิธีในการทำฟังก์ชั่นแบบอะซิงโครนัสasync Taskเป็นเพียงรูปแบบเดียวที่สร้างไว้ในคอมไพเลอร์ผ่านประเภทผลตอบแทนเพื่อให้คุณไม่ต้องเชื่อมโยงเหตุการณ์ด้วยตนเอง

ฉันจะพูดถึงประเด็นหลักในรูปแบบ C # Ness ที่น้อยลงและเป็นเรื่องทั่วไปมากขึ้น:

async / รอปฏิบัติที่ดีที่สุดไม่ตรงข้ามกับหลักการ "สถาปัตยกรรมที่ดี" หรือไม่?

ฉันจะบอกว่ามันขึ้นอยู่กับตัวเลือกที่คุณเลือกในการออกแบบ API และสิ่งที่คุณให้กับผู้ใช้

หากคุณต้องการให้หนึ่งฟังก์ชันของ API ของคุณเป็นแบบอะซิงก์เพียงอย่างเดียวความสนใจเพียงเล็กน้อยในการติดตามการตั้งชื่อจะเป็นอย่างไร เพียงแค่ส่งคืนงาน <> / สัญญา <> / อนาคต <> / ... เป็นประเภทส่งคืนเสมอมันเป็นเอกสารด้วยตนเอง หากต้องการคำตอบแบบซิงโครไนซ์เขาจะยังคงสามารถทำได้โดยรอ แต่ถ้าเขาทำอย่างนั้นตลอดมันจะทำให้หม้อไอน้ำเล็กน้อย

อย่างไรก็ตามหากคุณทำการซิงค์ API ของคุณเท่านั้นนั่นหมายความว่าหากผู้ใช้ต้องการให้เป็นแบบอะซิงโครนัสเขาจะต้องจัดการส่วน async ของมันเอง

สิ่งนี้สามารถทำงานได้ค่อนข้างมาก แต่ก็สามารถควบคุมผู้ใช้ได้มากขึ้นเกี่ยวกับจำนวนการโทรพร้อมกันที่เขาอนุญาตวางหมดเวลา retrys และอื่น ๆ

ในระบบขนาดใหญ่ที่มี API ขนาดใหญ่การใช้งานส่วนใหญ่ในการซิงค์โดยค่าเริ่มต้นอาจทำได้ง่ายกว่าและมีประสิทธิภาพมากกว่าการจัดการแต่ละส่วนของ API ของคุณโดยเฉพาะอย่างยิ่งหากพวกเขาแบ่งปันทรัพยากรระบบไฟล์ (CPU ระบบฐานข้อมูล ... )

ในความเป็นจริงสำหรับชิ้นส่วนที่ซับซ้อนที่สุดคุณสามารถมีการใช้งานสองส่วนที่เหมือนกันของ API ของคุณหนึ่งแบบซิงโครนัสทำสิ่งที่มีประโยชน์หนึ่งแบบอะซิงโครนัสที่อาศัยแบบซิงโครนัส .

บางทีคนอื่นสามารถแบ่งปันประสบการณ์ของเขากับที่เพราะฉันขาดประสบการณ์กับระบบดังกล่าว