บันทึกวัตถุด้วยวิธีการของตัวเองหรือผ่านชั้นเรียนอื่นได้หรือไม่

ถ้าฉันต้องการที่จะบันทึกและดึงวัตถุฉันควรสร้างคลาสอื่นเพื่อจัดการกับมันหรือมันจะดีกว่าที่จะทำในชั้นเรียนของตัวเอง? หรืออาจจะผสมทั้งสองอย่าง?

ข้อเสนอแนะใดบ้างตามกระบวนทัศน์ของ OOD

ตัวอย่างเช่น

Class Student
{
    public string Name {set; get;}
    ....
    public bool Save()
    {
        SqlConnection con = ...
        // Save the class in the db
    }
    public bool Retrieve()
    {
         // search the db for the student and fill the attributes
    }
    public List<Student> RetrieveAllStudents()
    {
         // this is such a method I have most problem with it 
         // that an object returns an array of objects of its own class!
    }
}

กับ (ฉันรู้ว่าแนะนำต่อไปนี้ แต่ดูเหมือนว่าฉันจะขัดกับความต่อเนื่องของStudentชั้น)

Class Student { /* */ }
Class DB {
  public bool AddStudent(Student s)
  {

  }
  public Student RetrieveStudent(Criteria)
  {
  } 
  public List<Student> RetrieveAllStudents()
  {
  }
}

วิธีการผสมพวกเขา

   Class Student
    {
        public string Name {set; get;}
        ....
        public bool Save()
        {
            /// do some business logic!
            db.AddStudent(this);
        }
        public bool Retrieve()
        {
             // build the criteria 
             db.RetrieveStudent(criteria);
             // fill the attributes
        }
    }

Single รับผิดชอบหลักการ , แยกความกังวลและการทำงานร่วมกันทำงาน หากคุณอ่านแนวคิดเหล่านี้คำตอบที่คุณได้รับคือ: แยกพวกเขาออก

เหตุผลง่ายๆในการแยกชั้นStudent"DB" (หรือStudentRepositoryเพื่อทำตามอนุสัญญาที่เป็นที่นิยมมากขึ้น) คือการอนุญาตให้คุณเปลี่ยน "กฎเกณฑ์ทางธุรกิจ" ของคุณนำเสนอในStudentชั้นเรียนโดยไม่ส่งผลกระทบต่อโค้ดที่รับผิดชอบต่อการติดตา ในทางกลับกัน

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

โดยการมีกฎเกณฑ์ทางธุรกิจและความเพียรอยู่ด้วยกันไม่ว่าจะเป็นชั้นเดียวอย่างในตัวอย่างแรกของคุณหรือด้วยDBการพึ่งพาStudentคุณกำลังมีข้อกังวลที่แตกต่างกันสองข้อ อาจดูเหมือนพวกเขาอยู่ด้วยกัน พวกเขาดูเหมือนจะเหนียวเพราะใช้ข้อมูลเดียวกัน แต่นี่คือสิ่งที่: การทำงานร่วมกันไม่สามารถวัดได้เพียงอย่างเดียวจากข้อมูลที่ใช้ร่วมกันระหว่างกระบวนการคุณต้องพิจารณาถึงระดับของสิ่งที่เป็นนามธรรม ในความเป็นจริงประเภทที่เหมาะที่สุดของการทำงานร่วมกันอธิบายว่า:

การทำงานร่วมกันคือเมื่อส่วนต่าง ๆ ของโมดูลถูกจัดกลุ่มเพราะพวกมันล้วนมีส่วนร่วมในภารกิจที่กำหนดไว้อย่างดีของโมดูล

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

ฉันขอแนะนำให้อ่านเกี่ยวกับสถาปัตยกรรมที่สะอาด , ดูการพูดคุยนี้เกี่ยวกับหลักการความรับผิดชอบเดี่ยว (ซึ่งมีการใช้ตัวอย่างที่คล้ายกันมาก) และดูการพูดคุยนี้เกี่ยวกับสถาปัตยกรรมที่สะอาดเช่นกัน แนวคิดเหล่านี้แสดงเหตุผลที่อยู่เบื้องหลังการแยกดังกล่าว

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

ดังนั้นหากคุณจะไม่เขียนโปรแกรมของเล่นใช้เลย ให้ใช้คลาสอื่นเช่น a StudentRepositoryเพื่อระบุ API สำหรับการโหลดและการบันทึกสมมติว่าคุณกำลังใช้โค้ด CRUD ด้วยตัวคุณเอง คุณอาจพิจารณาใช้เฟรมเวิร์กORMซึ่งสามารถทำงานหนักให้กับคุณได้ (และกรอบการทำงานจะบังคับใช้การตัดสินใจบางอย่างที่จำเป็นต้องวางการดำเนินการโหลดและบันทึก)

มีรูปแบบค่อนข้างน้อยที่สามารถใช้สำหรับการเก็บข้อมูล มีรูปแบบหน่วยงานมีรูปแบบพื้นที่เก็บข้อมูลมีรูปแบบเพิ่มเติมบางอย่างที่สามารถใช้งานได้เช่น Remote Facade และอื่น ๆ

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

ตามหมายเหตุด้านข้าง: ในตัวอย่างของคุณ RetrieveStudent, AddStudent ควรเป็นวิธีการแบบคงที่ (เนื่องจากไม่ได้ขึ้นอยู่กับอินสแตนซ์)

อีกวิธีหนึ่งของการมีวิธีการบันทึก / โหลดในระดับคือ:

class Animal{
    public string Name {get; set;}
    public void Save(){...}
    public static Animal Load(string name){....}
    public static string[] GetAllNames(){...} // if you just want to list them
    public static Animal[] GetAllAnimals(){...} // if you actually need to retrieve them all
}

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

โปรดดูรูปแบบหน่วยการทำงานด้วย เมื่อคุณได้รับรู้มันจะดีมากทั้งในกรณีเล็กและใหญ่ และได้รับการสนับสนุนจากเฟรมเวิร์ก / apis มากมายเพื่อตั้งชื่อ EntityFramework หรือ RavenDB

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

แต่ฉันคิดว่ามันคงยอดเยี่ยมมาก

แต่จะดีกว่าถ้าให้คลาสจัดการข้อมูลและฟังก์ชันการทำงาน (เช่นพลเมือง OO ที่ดี) และทำให้กลไกการคงอยู่ไปยังคลาสอื่นหรือชุดของคลาสภายนอก

ตัวเลือกอื่นคือการใช้เฟรมเวิร์กการคงอยู่ที่กำหนดการคงอยู่ที่ประกาศไว้ (เช่นเดียวกับคำอธิบายประกอบ) แต่นั่นก็ยังคงอยู่ภายนอกการคงอยู่

• กำหนดวิธีการในชั้นเรียนที่เป็นอันดับวัตถุและส่งกลับลำดับของไบต์ที่คุณสามารถใส่ในฐานข้อมูลหรือไฟล์หรืออะไรก็ตาม
• มีตัวสร้างสำหรับวัตถุนั้นที่ใช้ลำดับของไบต์เป็นอินพุต

เกี่ยวกับRetrieveAllStudents()วิธีการความรู้สึกของคุณถูกต้องมันอาจถูกวางผิดเพราะคุณอาจมีรายชื่อนักเรียนที่แตกต่างกัน ทำไมไม่เก็บรายการไว้นอกStudentห้องเรียน?