TL; DR:
Bir DTO, devlet aktarımının biçimini açıklar. Bir POCO hiçbir şey tanımlamaz. OOP'ta "nesne" demenin başka bir yolu. Bu, kelimenin tam anlamıyla 'nesne' için daha süslü bir isim olarak tanımlayan Martin Fowler tarafından kombine edilen POJO'dan (Java) geliyor, çünkü 'nesne' çok seksi değil.
DTO, durumu ilgili katmanlar arasında aktarmak için kullanılan bir nesne modelidir. Bu davranış durumu değiştirmediği sürece davranışları olabilir (teknik olarak bir poco olabilirler). Örneğin, kendini serileştiren bir yöntemi olabilir.
POCO düz bir nesnedir, ancak 'düz' ile kastedilen, özel olmadığıdır. Bu, zımni bir desene sahip olmayan bir CLR nesnesi olduğu anlamına gelir. Genel bir terim. Başka bir çerçeveyle çalışmak için yapılmamıştır. POCO'nuzda[JsonProperty] tüm özelliklerinde veya EF süslemelerine , o zaman bunun bir POCO olmadığını iddia ederim.
Burada karşılaştırılacak farklı nesne desenlerinin bazı örnekleri:
- Modeli Görüntüle : bir görünümdeki verileri modellemek için kullanılır. Genellikle ciltleme ve doğrulamaya yardımcı olacak veri ek açıklamalarına sahiptir. MVVM'de, aynı zamanda bir kontrolör görevi görür. Bir DTO'dan daha fazlası
- Değer Nesnesi : değerleri temsil etmek için kullanılır
- Agrega Kökü : eyalet ve değişmezleri yönetmek için kullanılır
- İşleyiciler : bir olaya / mesaja yanıt vermek için kullanılır
- Özellikler : kesişen endişelerle başa çıkmak için dekorasyon olarak kullanılır
- Hizmet : karmaşık görevleri yerine getirmek için kullanılır
- Denetleyici : isteklerin ve yanıtların akışını kontrol etmek için kullanılır
- Fabrika : Bir kurucu yeterince iyi olmadığında kullanılmak üzere karmaşık nesneleri yapılandırmak ve / veya birleştirmek için kullanılır. Ayrıca çalışma zamanında hangi nesnelerin oluşturulması gerektiğine karar vermek için kullanılır.
- Depo / DAO : verilere erişmek için kullanılır
Bunların hepsi sadece nesnelerdir, ancak çoğunun genellikle bir desene bağlı olduğuna dikkat edin. Böylece onlara “nesneler” diyebilir ya da niyetiyle ilgili daha spesifik olabilir ve ne olduğunu söyleyebilirsiniz. Bu yüzden tasarım kalıplarımız da var; birkaç eserde karmaşık kavramları tanımlamak. DTO bir kalıptır. Agrega kökü bir kalıptır, Görünüm Modeli bir kalıptır (örn. MVC ve MVVM). POCO bir model değildir.
Bir POCO bir patern tanımlamaz. OOP'taki sınıflara / nesnelere atıfta bulunmanın sadece farklı bir yoludur. Bunu soyut bir kavram olarak düşünün; her şeye atıfta bulunabilirler. IMO, tek yönlü bir ilişki var çünkü bir nesne temiz bir şekilde sadece bir amaca hizmet edebileceği noktaya ulaştığında, artık bir POCO değil. Örneğin, bir çerçeveyle çalışmasını sağlamak için sınıfınızı süslemelerle işaretlediğinizde, artık bir POCO değildir. Bu nedenle:
- DTO bir POCO'dur
- Bir POCO bir DTO değildir
- Bir Görünüm Modeli bir POCO'dur
- POCO bir Görünüm Modeli değildir
İkisi arasında bir ayrım yapmanın amacı, endişeleri aşmamak ve sıkı birleşmeye yol açmamak için kalıpları açık ve tutarlı tutmaktır. Örneğin, durumu değiştirmek için yöntemlere sahip, ancak aynı zamanda bir API uç noktası üzerinden geri gönderilebilmesi için SQL Server VE JsonProperty'ye kaydetmek için EF süslemeleri ile cehenneme dekore edilmiş bir iş nesneniz varsa. Bu nesne değiştirilmeye karşı toleranssızdır ve muhtemelen bazı özelliklerin DB'ye kaydedilmeyecek şekilde işaretlendiği ve diğerlerinin API bitiş noktasında JSON).
Bana bir şeyin DTO olduğunu söyleseydiniz, muhtemelen durumu hareket etmekten başka hiçbir şey için kullanılmadığından emin olurdum. Bana bir görünüm modeli olduğunu söylediyseniz, muhtemelen bir veritabanına kaydedilmediğinden emin olurdum. Bana bir alanın Modeli olduğunu söylediyseniz, muhtemelen alanın dışındaki herhangi bir şeye bağımlılığı olmadığından emin olurdum. Ama bana bir şeyin POCO olduğunu söyleseydin, bana gerçekten fazla bir şey söylemezdin.