[N-tier] [Architecture] POCO vs DTO

[nameless]

selamlar kankuliler,

poco (plain old clr object) ve dto (data transfer object) tanımları konusunda anlamadığım bir şey var. baya bir araştırma yaptım ama hala ikisi de aynı kavramlarmış gibi geliyor bana.

poco dediğimiz persistance ignorant. yani veriye nasıl ulaşıldığını bilmiyor; dto da aynı şekilde. ikisi de veriyi encapsulate ediyor, sadece public property'lerden oluşuyorlar.

benim düşündüğüm poco'larda validation da olması gerektiği.

n-tier yapıda da veri şu şekilde ilerler gibi geliyor.

entity -> poco -> dto -> bo (bussiness object)

yanlış mı düşünüyorum. n-tier mimari konusunda tecrübeli arkadaşlar yardımcı olursa sevinicem vallahi :D:D:D:D:D

iyi forumlar

[reyou]

bende Object oriented ile MVC arasindan bi iliski varmi onu kestirmeye calisiyorum, konu icinde konu gibi olmasin ama, biride arada bunu anlatirsa cok sevinirim :D

[Ractamainus]

aralarındaki fark aslında mantıksal bir bakış açısından kaynaklı, zira ikisinin de amacı veriyi tier'lar arasında transfer etmek.

ama poco, .net-vari bir obje yaklaşımıyla (ya da oop diyelim) veriyi objelere bölüp anlamlandırıyor ve her objenin kendi davranış biçimine göre davranıyor. o davranış biçimi içinde validation da var tabii ki, property'lere erişim biçimleri de.. sadece persistence method'ları yok (dto gibi). bu anlamda poco business object'e daha yakın.

dto ise daha geniş davranıyor. anlamlı objelere göre hiyerarşik bir bölünmeye gitmiyor da bir sonraki tier'da ihtiyaç olunan veriyi içinde barındırıyor.

misal bunu mvc yapısında düşünürsek, model'den gelen veriyi controller'da poco olarak işledikten sonra, bunu view'a vereceğiz.. ama view için anlamlı olan poco olmuyor sıklıkla. atıyorum sayfada hem kullanıcı bilgileri, hem tarih, hem şirket bilgisi, hem bilmemne dinamik olarak aynı anda gösterilecek. bunu poco ile taşımak masraflı çünkü kullanıcı ayrı,şirket ayrı, bilmemne ayrı bir obje (ve başka sebepleri de olabilir, daha anlaşılabilir olmak gibi, bilmiyorum...), o yüzden dto ile view'a transfer ediliyor. gibi..

[senko]

poco dedıgınız pojo mu? :)

racta, pojo ile view'e veri saglamak jsf ile bayagi kolay, hani benzer bir framework kullanilirsa is kotarilir bence.

[nameless]

@Ractamainus

teşekkürler açıklama için. dto'larda persistence awarness var söylediğine göre. aslında dao'lar ya da entity'ler persistence aware değil mi?

repository pattern için anlamaya çalışıyorum tanımlamaları. sadece ef'ye bağımlı kod yazmak basite kaçmak gibi geliyor. sharepoint development ile uğraştığım için verinin gelebileceği farklı kaynaklar olabiliyor. sharepoint listesi ya da sql server gibi. neden sql server'a ihtiyaç duyuyorsun derseniz olay şu: sharepoint listeleri karmaşık yapılarda patlıyor. linq to sharepoint'te de lazy loading gibi bir olay ya da self reference ve çoklu reference olaylarında sorun çıkarmasa sadece linq to sharepoint devam edebilirim.

repository pattern için pseudo ya da .net üzerine güzel bir kaynak paylaşabilir misin? ben bir çok kaynak buldum ama hep bir design flow görüyorum. zaten repository'de abstraction over abstraction gibi bir sorun var.

ayrıca, ef üzerine tecrüben ya da başkalarının tecrübesi varsa change traking ile ilgili (ef proxy change tracking değil)nasıl bir implementasyon yapılmalıdır.

baya wall of text oldu ama burada paylaşılanlar mimari konusunda baya kişiye yardımcı olur gibi geliyor.

@senko

poco, pojo'nun .net'çesi.

[Ractamainus]

yok abi o benim cümlemin yamukluğu olmuş, dto'larda persistence awarness yok. poco'da var. ama her ikisinde de persistence methods yok.

ef ile sharepoint çok iyi bir practice değil bence. denemeleri var ama mimari olarak zorlama geliyor. bir kere .net framework versiyonları farklı son versiyonlarla (.net 3.5 - .net 4) ve sp application pool'unda direkt koşturamayacağından, tamamen ayırman ve servis katmanı oluşturman gerekiyor ki çok gereksiz olur bence. halihazırda arayüzünü silverlight falan yapsan, wcf ile konuşsan olabilir diyebilirdim (ki bu da servisinin nerede olacağı ve ne yapacağıyla yine çok ilgili).

yapısal olarak büyük olacak ya da transaction'ın çok olacağı bir db'yi splist olarak tasarlamak da akıl karı değil, kesinlikle haklısın. ciddi problemlerin oluyor.

bu durumda da (teoride) kendi db'lerine bağlı bcs öneriyorlar ki bence berbat bir seçim. en basitinden lookup fieldlarda update problemleriyle yüzleşiyorsun. karmaşık yapılara uygun değil. bsc benim için daha çok read-only bir çözüm olabilir.

en iyisi kendi db yapını tasarlayıp, custom orm framework'unu yazmak olabilir. bazı konfigürasyonel referans verilerini de splist'lerde tutmak.

yani sharepoint api'ı var, db ile işiniz yok falan biraz işin yalan tarafı. ms'e sorsan, sharepoint api ile her şeyi yapıyorsun. ama kesinlikle best practice değil. hatta bazı durumlarda kabul edilebilir bir şey bile değil.

ef ile pek tecrübem yok çünkü ben de genel olarak sharepoint üzerinde çalışıyorum =) sql change tracking'den bahsediyorsun ama sanırım? bunun için ef'e de ihtiyacın yok, ef üzerinden mi gitmek istiyorsun?

repository pattern üzerine ben de dediğin ibi makaleler arıyorum aslında =) bu konuda en çok mevcut projeleri inceleyerek fikir sahibi oldum esasen. bahsettiğin gibi bir makale ben de bulamıyorum bu konularda..

senko, .net'de de framework'ler var zaten poco için ve çok kolay kullanımları (aslında bazen de zor). ama bizim tartıştığımız işin daha çok hiyerarşik yanı, bunu hiç bir framework çözemiyor aslında. konu frameworkü nasıl bir metodolojiyle kullandığın çünkü, işin felsefesi gibi bişey.

[nameless]

ef ile sharepoint'i kullandığımı düşünerek yazmışsın ilk paragrafı ama diğer paragraflarda açıkladığın yöntemleri bire bir bu hafta beta test'e çıkan bir projede kullandık. aklın yolu bir heheh

change tracking'ten kastım ef'deki change tracking olayı. poco entity'lerini property'leri virtual yapıp context'te change tracking'i enable etme. benim merak ettiğim bunu custom uygulama şansımız nasıl olur çünkü açıklamalarında change tracking çok düşük bir cost ile oluyor diyorlar. snapshot vs. gibi değilmiş (onların yalancısıyım).

bu arada entity framework ile ilgili en iyi kaynak bu amca: http://stackoverflow.com/users/413501/ladislav-mrnka