ความสัมพันธ์ระหว่างพื้นที่เก็บข้อมูลกับหน่วยงาน


17

ฉันจะใช้พื้นที่เก็บข้อมูลและฉันต้องการใช้รูปแบบ UOW เนื่องจากผู้บริโภคของที่เก็บสามารถดำเนินการหลายอย่างและฉันต้องการที่จะยอมรับพวกเขาในครั้งเดียว

หลังจากอ่านบทความต่าง ๆ เกี่ยวกับเรื่องนี้แล้วฉันยังไม่เข้าใจวิธีการเชื่อมโยงองค์ประกอบทั้งสองนี้ขึ้นอยู่กับบทความที่กำลังทำในลักษณะอื่น ๆ

บางครั้ง UOW เป็นสิ่งที่อยู่ภายในที่เก็บ:

public class Repository
{
    UnitOfWork _uow;

    public Repository()
    {
       _uow = IoC.Get<UnitOfWork>();
    }

    public void Save(Entity e)
    {
        _uow.Track(e);
    }

    public void SubmittChanges()
    {
        SaveInStorage(_uow.GetChanges());
    }
}

และบางครั้งก็เป็นภายนอก:

public class Repository
{
    public void Save(Entity e, UnitOfWork uow)
    {
        uow.Track(e);
    }

    public void SubmittChanges(UnitOfWork uow)
    {
        SaveInStorage(uow.GetChanges());
    }
}

เวลาอื่นคือ UOW ที่อ้างอิงถึงที่เก็บ

public class UnitOfWork
{
    Repository _repository;

    public UnitOfWork(Repository repository)
    {
       _repository = repository;
    }

    public void Save(Entity e)
    {
        this.Track(e);
    }

    public void SubmittChanges()
    {
       _repository.Save(this.GetChanges());
    }
}

องค์ประกอบทั้งสองนี้เกี่ยวข้องกันอย่างไร UOW ติดตามองค์ประกอบที่จำเป็นต้องเปลี่ยนแปลงและที่เก็บมีตรรกะเพื่อยืนยันการเปลี่ยนแปลงเหล่านั้น แต่ ... ใครโทรหาใคร คนสุดท้ายมีเหตุผลมากกว่านี้ไหม?

ใครจัดการการเชื่อมต่อด้วย? หากต้องทำการดำเนินการหลายอย่างในที่เก็บฉันคิดว่าการใช้การเชื่อมต่อเดียวกันและแม้แต่การทำธุรกรรมก็เป็นเสียงที่มากกว่าดังนั้นอาจวางวัตถุการเชื่อมต่อใน UOW และสิ่งนี้ภายในที่เก็บข้อมูลก็สมเหตุสมผลเช่นกัน

ไชโย


คำตอบ:


7

Re: "UOW ติดตามองค์ประกอบที่จำเป็นต้องเปลี่ยนแปลงและพื้นที่เก็บข้อมูลมีตรรกะเพื่อยืนยันการเปลี่ยนแปลงเหล่านั้น แต่ ... ใครโทรหาใคร"

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

ฉันพยายามที่จะร่างปัญหาในแง่ของ 'เลเยอร์' ในขณะที่ถูกชี้นำโดยผู้บริหารขั้นพื้นฐานของการออกแบบซอฟต์แวร์ที่ดีเช่นCohesion , Decoupling , Reusability , Unit-Testabilityเป็นต้น

ในการอ้างอิงการออกแบบที่ขับเคลื่อนด้วย Eric Evans Domain, (2004) Addison Wesley, pg 69 :

หลักการสำคัญ [ของ Layered Archituctures] คือองค์ประกอบใด ๆ ของชั้นขึ้นอยู่กับองค์ประกอบอื่น ๆ ในชั้นเดียวกันหรือองค์ประกอบของชั้น "ใต้"

ในความเห็นของฉันทั้ง UOW และ Repo เป็นสองชั้นที่แตกต่างกันมากซึ่งมีความชัดเจนเป็นอิสระและมีความรับผิดชอบ เพื่อเริ่มต้นด้วยฉันจะไม่เรียกทั้งสองอื่น ๆ

ฉันคิดว่าคุณต้องมีสามลูกค้าระดับ (เช่นอย่างใดอย่างหนึ่งcontrollerหรือservice class) ที่จริงๆรู้ว่า 'เวลาและสิ่งที่จะได้รับจากการซื้อคืนและ 'เมื่อ' เพื่อบันทึกการทำธุรกรรม ลูกค้ารายนี้อยู่ค่อนข้างสูงในสถาปัตยกรรม (เพื่อให้สามารถรู้เกี่ยวกับชั้นเรียนเพิ่มเติม) และสามารถทำการประสานระหว่างทั้งสอง

--------------------------------

         [Client]
           /   \
----------/---- \---------------
         /       \
        V         V
[Unit Of Work]  [Repo]


--------------------------------

2

วิธีการส่วนใหญ่จะมอบให้กับอินเทอร์เฟซ UOW (ซึ่งโดยปกติจะสร้างผ่านโรงงาน)

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

Microsoft มีการโพสต์อย่างละเอียดมากในรูปแบบ UOW:

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.