Lưu một đối tượng thông qua một phương thức của chính nó hoặc thông qua một lớp khác?

Nếu tôi muốn lưu và lấy một đối tượng, tôi có nên tạo một lớp khác để xử lý nó hay không, tốt hơn là nên làm điều đó trong chính lớp đó? Hoặc có thể trộn cả hai?

Đó là khuyến cáo theo mô hình OOD?

Ví dụ

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

Đấu với. (Tôi biết những điều sau được khuyến nghị, tuy nhiên đối với tôi có vẻ hơi chống lại sự gắn kết của Studentlớp học)

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

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

Làm thế nào về việc trộn chúng?

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

Nguyên tắc trách nhiệm duy nhất , tách biệt mối quan tâm và sự gắn kết chức năng . Nếu bạn đọc các khái niệm này, câu trả lời bạn nhận được là: Tách chúng ra .

Một lý do đơn giản để tách lớp Student"DB" (hoặc StudentRepository, theo các quy ước phổ biến hơn) là cho phép bạn thay đổi "quy tắc kinh doanh" của mình, hiện diện trong Studentlớp, mà không ảnh hưởng đến mã chịu trách nhiệm cho sự kiên trì và ngược lại ngược lại

Loại tách biệt này rất quan trọng, không chỉ giữa quy tắc kinh doanh và sự kiên trì, mà giữa nhiều mối quan tâm của hệ thống của bạn, cho phép bạn thực hiện các thay đổi với tác động tối thiểu trong các mô-đun không liên quan (tối thiểu vì đôi khi không thể tránh khỏi). Nó giúp xây dựng các hệ thống mạnh hơn, dễ bảo trì hơn và đáng tin cậy hơn khi có những thay đổi liên tục.

Bằng cách có các quy tắc kinh doanh và sự kiên trì trộn lẫn với nhau, hoặc là một lớp duy nhất như trong ví dụ đầu tiên của bạn, hoặc với DBtư cách là một phụ thuộc Student, bạn đang kết hợp hai mối quan tâm rất khác nhau. Có vẻ như họ thuộc về nhau; chúng dường như được gắn kết bởi vì chúng sử dụng cùng một dữ liệu. Nhưng đây là điều: sự gắn kết không thể được đo lường chỉ bằng dữ liệu được chia sẻ giữa các thủ tục, bạn cũng phải xem xét mức độ trừu tượng mà chúng tồn tại. Trong thực tế, loại kết dính lý tưởng được mô tả là:

Sự gắn kết chức năng là khi các bộ phận của một mô-đun được nhóm lại bởi vì tất cả chúng đều góp phần vào một nhiệm vụ được xác định rõ của mô-đun.

Và rõ ràng, thực hiện xác nhận Studenttrong một thời gian cũng tồn tại nó không hình thành "một nhiệm vụ được xác định rõ". Vì vậy, một lần nữa, các quy tắc kinh doanh và cơ chế kiên trì là hai khía cạnh rất khác nhau của hệ thống, theo nhiều nguyên tắc thiết kế hướng đối tượng tốt, nên được tách biệt.

Tôi khuyên bạn nên đọc về Kiến trúc sạch , xem bài nói này về Nguyên tắc trách nhiệm duy nhất (nơi sử dụng một ví dụ rất giống nhau) và cũng xem bài nói về Kiến trúc sạch này . Những khái niệm này phác thảo những lý do đằng sau sự tách biệt như vậy.

Cả hai cách tiếp cận đều vi phạm Nguyên tắc Trách nhiệm duy nhất. Phiên bản đầu tiên của bạn cung cấp cho Studentlớp nhiều trách nhiệm và liên kết nó với một công nghệ truy cập DB cụ thể. Thứ hai dẫn đến một DBlớp học lớn sẽ chịu trách nhiệm không chỉ đối với sinh viên mà còn đối với bất kỳ loại đối tượng dữ liệu nào khác trong chương trình của bạn. EDIT: cách tiếp cận thứ ba của bạn là tồi tệ nhất, vì nó tạo ra sự phụ thuộc theo chu kỳ giữa lớp DB và Studentlớp.

Vì vậy, nếu bạn sẽ không viết một chương trình đồ chơi, không sử dụng chúng. Thay vào đó, hãy sử dụng một lớp khác như StudentRepositorycung cấp API để tải và lưu, giả sử bạn sẽ tự mình thực hiện mã CRUD. Bạn cũng có thể cân nhắc sử dụng khung ORM , có thể thực hiện công việc khó khăn cho bạn (và khung thường sẽ thi hành một số quyết định trong đó các hoạt động Tải và Lưu phải được đặt).

Có khá nhiều mẫu có thể được sử dụng để duy trì dữ liệu. Có mẫu Đơn vị công việc , có mẫu Kho lưu trữ , có một số mẫu bổ sung có thể được sử dụng như Mặt tiền từ xa, v.v.

Hầu hết những người có người hâm mộ và các nhà phê bình của họ. Thông thường phải chọn những gì có vẻ phù hợp nhất với ứng dụng và gắn bó với nó (với tất cả các nhược điểm của nó, tức là không sử dụng cả hai mẫu cùng một lúc ... trừ khi bạn thực sự chắc chắn về điều đó).

Như một lưu ý phụ: trong ví dụ của bạn là RetrieveStudent, AddStudent phải là các phương thức tĩnh (vì chúng không phụ thuộc vào thể hiện).

Một cách khác để có các phương thức lưu / tải trong lớp là:

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
}

Cá nhân tôi chỉ sử dụng cách tiếp cận như vậy trong một ứng dụng khá nhỏ, có thể là các công cụ để sử dụng cá nhân hoặc nơi tôi có thể dự đoán một cách đáng tin cậy rằng tôi sẽ không gặp trường hợp sử dụng phức tạp hơn là chỉ lưu hoặc tải đối tượng.

Còn cá nhân, xem mẫu Đơn vị công việc. Khi bạn làm quen với nó, nó thực sự tốt trong cả trường hợp nhỏ và lớn. Và nó được hỗ trợ bởi rất nhiều khung / apis, để đặt tên EntityFramework hoặc RavenDB chẳng hạn.

Nếu đó là một ứng dụng rất đơn giản trong đó đối tượng ít nhiều bị ràng buộc với kho dữ liệu và ngược lại (nghĩa là có thể được coi là một thuộc tính của kho dữ liệu), thì có một phương thức .save () cho lớp đó có thể có ý nghĩa.

Nhưng tôi nghĩ rằng nó sẽ khá đặc biệt.

Thay vào đó, tốt hơn là để cho lớp quản lý dữ liệu và chức năng của nó (như một công dân OO tốt) và đưa cơ chế bền bỉ sang một lớp khác hoặc tập hợp các lớp.

Tùy chọn khác là sử dụng một khung kiên trì xác định khai báo bền bỉ (như với các chú thích), nhưng điều đó vẫn xuất hiện bên ngoài sự tồn tại.

• Xác định một phương thức trên lớp đó tuần tự hóa đối tượng và trả về một chuỗi byte mà bạn có thể đặt trong cơ sở dữ liệu hoặc tệp hoặc bất cứ thứ gì
• Có một hàm tạo cho đối tượng đó lấy một chuỗi byte như vậy làm đầu vào

Về RetrieveAllStudents()phương pháp, cảm giác của bạn là đúng, nó thực sự có thể bị đặt sai chỗ, bởi vì bạn có thể có nhiều danh sách sinh viên khác nhau. Tại sao không chỉ đơn giản là giữ (các) danh sách bên ngoài Studentlớp học?