Bir nesneyi kendine ait bir yöntemle veya başka bir sınıfla mı kaydetmek?

Bir nesneyi kaydetmek ve almak istersem, onu işlemek için başka bir sınıf mı oluşturmalıyım, yoksa bunu sınıfın kendisinde mi yapmalıyım? Ya da belki her ikisini de karıştırıyor?

OOD paradigmasına göre hangisi önerilir?

Örneğin

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

E karşı. (Aşağıdakilerin tavsiye edildiğini biliyorum, ancak bana Studentsınıfın uyumuna karşı biraz görünüyor )

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

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

Onları karıştırmaya ne dersiniz?

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

Tek Sorumluluk İlkesi , Endişelerin Ayrılması ve İşlevsel Uyum . Bu kavramları okuyorsanız, aldığınız cevap: Onları ayırın .

Student"DB" sınıfından (veya StudentRepositorydaha popüler sözleşmelere uymak için) ayrılmanın basit bir nedeni , Studentsınıfta mevcut olan "iş kurallarınızı" kalıcılıktan sorumlu kodu etkilemeden değiştirmenize izin vermektir. versa.

Bu tür ayrılıklar, sadece iş kuralları ve ısrarlar arasında değil, aynı zamanda ilgisiz modüller üzerinde minimum etkiye sahip değişiklikler yapmanıza izin vermek için sisteminizin birçok kaygısı arasında da çok önemlidir (en azından çünkü kaçınılmazdır). Sürekli değişiklikler olduğunda bakımı daha kolay olan ve daha güvenilir olan daha sağlam sistemler kurmaya yardımcı olur.

İş kurallarını ve kalıcılığı bir araya getirerek, ya ilk örneğinizdeki gibi tek bir sınıf ya DBda bir bağımlılık olarak Student, çok farklı iki kaygıyı birleştiriyorsunuz. Birbirlerine aitmiş gibi görünebilir; aynı verileri kullandıkları için uyumlu görünüyorlar. Fakat işte mesele: uyum yalnızca prosedürler arasında paylaşılan verilerle ölçülemez, aynı zamanda var oldukları soyutlama seviyesini de göz önünde bulundurmalısınız. Aslında, ideal uyum tipi:

İşlevsel uyum , bir modülün parçaları gruplandığı zamandır, çünkü hepsi modülün iyi tanımlanmış tek bir görevine katkıda bulunur.

Ve açıkça, bir Studentsüredir devam eden doğrulamaların yapılması, "iyi tanımlanmış tek bir görev" oluşturmaz. Bu yüzden yine, iş kuralları ve sebat mekanizmaları, sistemin iyi nesneye yönelik tasarım prensipleriyle ayrı tutulması gereken çok farklı iki yönüdür.

Temiz Mimari hakkında okumayı , Tek Sorumluluk İlkesi (çok benzer bir örnek kullanıldığında) hakkındaki konuşmaları izlemenizi ve Temiz Mimari hakkında da bu konuşmayı izlemenizi öneririm . Bu kavramlar, bu ayrımların ardındaki nedenleri özetlemektedir.

Her iki yaklaşım da Tek Sorumluluk İlkesini ihlal ediyor. İlk versiyon, Studentsınıfa birçok sorumluluk verir ve belirli bir DB erişim teknolojisine bağlar. İkincisi, DByalnızca öğrencilerden değil programınızdaki diğer herhangi bir veri nesnesinden sorumlu olacak büyük bir sınıfa yol açar . EDIT: üçüncü yaklaşımınız en kötüsüdür, çünkü DB sınıfı ve sınıf arasında döngüsel bir bağımlılık yaratır Student.

Eğer bir oyuncak programı yazmayacaksanız, hiçbirini kullanmayın. Bunun yerine, StudentRepositoryCRUD kodunu kendi başınıza uygulayacağınızı farz edersek, yükleme ve kaydetme için bir API sağlamak için farklı bir sınıf kullanın . Ayrıca , sizin için zor olan işleri yapabilen bir ORM çerçevesi kullanmayı düşünebilirsiniz (ve çerçeve genellikle Yükleme ve Kaydet işlemlerinin yerleştirilmesi gereken bazı kararları uygular).

Veri kalıcılığı için kullanılabilecek birkaç kalıp vardır. Orada çalışmak Birim deseni vardır, Depo ve bu kadar uzaktan Cephe gibi kullanılabilir ve bazı ek desenler vardır, deseni.

Bunların çoğunun hayranları ve eleştirmenleri var. Genelde, uygulamaya en uygun olanı seçmek ve buna bağlı kalmak (geleceğin ve dezavantajları olan, yani aynı anda her iki modeli de kullanmamak ... aynı zamanda emin değilseniz) gelir.

Bir yan not olarak: Örneğinizde, RetrieveStudent, AddStudent, statik yöntemler olmalıdır (çünkü bunlar örnek bağımlı değildir).

Sınıf içi kaydetme / yükleme yöntemlerine sahip olmanın başka bir yolu:

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
}

Şahsen, bu tür bir yaklaşımı sadece oldukça küçük uygulamalarda, muhtemelen kişisel kullanım için olan araçlarda veya yalnızca nesneleri kaydetmek veya yüklemek yerine daha karmaşık kullanım durumlarına sahip olmayacağımı güvenilir bir şekilde tahmin edebileceğim durumlarda kullanırdım.

Ayrıca kişisel olarak, İş Birimi modeline bakın. Bunu tanıdığınızda, hem küçük hem de büyük durumlarda gerçekten iyidir. Ve örneğin EntityFramework veya RavenDB'yi isimlendirmek için birçok çerçeve / apis tarafından desteklenir.

Nesnenin veri deposuna ya da tam tersine bağlı olduğu çok basit bir uygulama ise (yani veri deposunun bir özelliği olarak düşünülebilir), o zaman bu sınıf için bir .save () yöntemi kullanmak mantıklı olabilir.

Fakat bunun oldukça istisnai olacağını düşünüyorum.

Aksine, sınıfın verilerini ve işlevselliğini (iyi bir OO vatandaşı gibi) yönetmesini sağlamak ve kalıcılık mekanizmasını başka bir sınıfa veya sınıflara dışlamak için genellikle daha iyidir.

Diğer seçenek, ısrarı bildirimsel olarak tanımlayan bir kalıcılık çerçevesi kullanmaktır (ek açıklamalarda olduğu gibi), ancak bu da ısrarı dışsallaştırmaktadır.

• Nesneyi serileştiren bir sınıf tanımlayın ve bir veritabanına veya dosyaya koyabileceğiniz bir bayt sırası döndürür.
• Girdi gibi bir bayt dizisi alan bu nesne için bir yapıcıya sahip olma

Hakkında RetrieveAllStudents()Eğer öğrenci birden çok farklı listeleri olabilir çünkü yöntemine bağlı olarak, duygu, sağ, gerçekten muhtemelen yanlış olmasıdır. Neden listeyi / Studentsınıfları sınıf dışında tutmuyorsun ?