Saf POCO modellerine sahip olmanın faydası nedir?

Saf POCO modellerine sahip olmanın en büyük yararı nedir? Modellerin temiz ve basit olması gerektiğini anlıyorum, ancak alt nesnelerin bakımını model sınıfları içinde tutmaya eğilimliyim. Örneğin, a ClassAve ClassBaşağıdaki gibi tanımlanmışsa:

public class ClassA
{
    public string MyProp { get; set; }
    public IEnumerable<ClassB> Children { get; }

    public void AddChild(ClassB newChild) { /*... */ }
    public void RemoveChild(ClassB child) { /* ... */ }
}

public class ClassB
{
    public string SomeProp { get; set; }
} 

Ekle ve kaldır yöntemlerine sahip olmanın doğasında yanlış olan bir şey var mı? Bunun yerine sadece listeyi açığa çıkarmalı ve istemci kodunun, null değil ve başka bir sınıfa çoğaltılmaması gibi basit veri doğrulamalarının sorumluluğunu geçen her şeyi eklemesine izin vermeli miyim?

Herhangi bir yardım için teşekkür ederiz.

İki sorunuz ilgisiz.

Saf POCO modellerine sahip olmanın faydası nedir?

Saf bir POCO, bazı girişimsel çerçeveye, sözleşmeye, [] bir şeye bağımlı değildir veya benzer şekilde bağımlı olan bir nesneye yakın bir şekilde bağlı değildir. Başka bir deyişle, dünya bir POCO etrafında tamamen değişebilir ve sadece umursamadan yaptıklarını yapmaya devam eder. Bir çerçeveyi güncelleyerek, yeni bir sisteme taşıyarak veya komik bir şekilde bakarak onu kıramazsınız. Sadece çalışmaya devam ediyor. Tek bağımlılıklar açıkça istediği şeylerdir.

POCO, POJO fikrinden başka bir şey değildir. J, bir C olarak değiştirildi, çünkü insanlar C # kullanıyorsa, adında Java olan bir kavramı açıkladığınızda insanlar size komik bakıyor. Fikir dile bağlı değildir. Basitçe Düz Eski Nesneler diyebilirlerdi. Ama kim POO kullanma konusunda övünmek istiyor?

Fowler'in kökenlerini açıklamasına izin vereceğim:

Terim Rebecca Parsons, Josh MacKenzie ve ben Eylül 2000'de bir konferansta konuşmaya hazırlanırken ortaya çıktı. Konuşmada, işletme mantığını Entity Beans kullanmak yerine normal java nesnelerine kodlamanın birçok faydasına işaret ediyorduk. İnsanların sistemlerinde normal nesneleri kullanmaya karşı niye bu kadar karşılandıklarını merak ettik ve bunun basit nesnelerin süslü bir adı olmadığı için olduğu sonucuna vardık. Bu yüzden onlara bir tane verdik ve çok güzel bir şekilde yakalandı.

martinfowler.com: POJO

Diğer sorunuza gelince:

Ekle ve kaldır yöntemlerine sahip olmanın doğasında yanlış olan bir şey var mı?

ADoğrudan bilmek hoşuma gitmiyor B. Ama bu bir DIP şey değil, bir POJO şey.

Ekle ve Kaldır ile Collection<T>özellikler uyguluyorsunuz . Kendinize, başka bir değişken sınıf IEnumerable<T>yerine neden kullandığınızı sorun. List<T>Görünüşe göre değil çünkü koleksiyonunuz salt okunur olmalıdır.

Düşünebilmemin tek nedeni, hangi erişim yöntemlerini yayınlamak istediğinizi kontrol etmek istemenizdir. Bu durumda, kendi toplama sınıfınızı oluşturmak, bir listeyi kapsüllemek, Ekle ve Kaldır ve uygulamak için seçtiğiniz yöntemleri uygulamak daha iyi olurdu IEnumerable<T>. Sonra IEnumerable<T>çocuk koleksiyonunuzun türü yerine bunu kullanın .

Ama bana öyle geliyor List<ClassB>ki muhtemelen sana iyi hizmet ederdi.

Ne AddChildekler ve ne RemoveChildkaldırır? Veritabanından (veya her türlü kalıcılık deposundan) ise, bir tür Aktif Kayıt elde edersiniz. Her zaman kötü bir şey olmak zorunda değildir, ancak kesinlikle @CandiedOrange'dan bahsedildiği gibi çerçeveler, sözleşmeler, bağımlılıklar vb.

Aynı zamanda, hepsi aynı uygulamadaysa ClassA'dan ClassB'ye (veya en azından InterfaceB) bağımlılıktan kaçınmanın anlamı nedir? Uygulamanızın modellediği gerçek dünya etki alanında işler birbirine bağlıdır. Gerçek dünya nesneleri yapmak olduğunu "aittir" onlara diğer nesnelerin koleksiyonları var. Kodunuzdaki bu ilişkileri temsil etmek tamamen uygundur.

Hatta biraz karmaşık hale gelmesinin tek nedeni, bir ClassB'nin ClassA ile nasıl ilişkilendirildiğini ve ClassA ile nasıl ilişkisiz hale geldiğini tam olarak yönetmeniz gerektiğine benziyor. Yani uygulamak için küçük bir davranışınız var. Sınıf içinde uygulayabilirsiniz (tamamen "yasal"; bkz. Https://stackoverflow.com/a/725365/44586 ) veya bu davranışı içeren bir tür ayrı sınıfa sahip olabilirsiniz. Bireysel koşullarınız için en anlamlı olanı yapın.

Her durumda, POJO / POCO gerçekten OOP, süslenmemiş ve numaralandırılmamış olması gerektiği gibi. OOP ilkelerini izleyin ve güvende olacaksınız.