Entity model(Poco class) ve view model karmaşası hakkında
83 views
Skip to first unread message
sbakir
May 18, 2012, 7:50:09 AM5/18/12
to altdotnetturkiye
"Entity modellerimizi , UI(view) tarafında kullanmamak için view
modellerimizi oluşturmalıyız" diye bir fikir üzerine birşey sormak
istiyorum
+ tarafları
Entity modellerimizde kullanılan bazı propertyler view(UI) tarafında
kullanılmıyor.Bu yüzden gereksiz yere bunları view katmanımıza
taşımaya gerek yok
Entity modellerimizde yapacağımız bir değişiklik ile direk olarak
view(UI) tarafının etkilenmesini engellemiş oluruz
- tarafları
Databaseden veri >>>entity model>>>view model şeklinde bir map/
convert işlemi büyük datalarda performansı düşürebilir.
View(UI) de yeni ekleyeciğimiz bir property için Entity model ve view
model e dokunmak zorunda kalıcaz.
Poco classlarımızın Datannotion özelliklerini View tarafına yansıtma
özelliği ortadan kalkacak.örn..poco modelimiz MaxLength=20
attributes ini eklediğimizde bu direk
view e yansıyorken, View modelerimiz i kullandığımızdan artık bu durum
ortadan kalkacak.
Bu bahsettiğim durum ile mvc de karşılaşmıştım.Entity model ile UI
tarafanını ilişkisini tamamen koparıp view mdelleri kullanınca bu
sorunlar ortaya çıkmıştı.
Sizin fikirleriniz merak ediyorum
modellerimizi oluşturmalıyız" diye bir fikir üzerine birşey sormak
istiyorum
+ tarafları
Entity modellerimizde kullanılan bazı propertyler view(UI) tarafında
kullanılmıyor.Bu yüzden gereksiz yere bunları view katmanımıza
taşımaya gerek yok
Entity modellerimizde yapacağımız bir değişiklik ile direk olarak
view(UI) tarafının etkilenmesini engellemiş oluruz
- tarafları
Databaseden veri >>>entity model>>>view model şeklinde bir map/
convert işlemi büyük datalarda performansı düşürebilir.
View(UI) de yeni ekleyeciğimiz bir property için Entity model ve view
model e dokunmak zorunda kalıcaz.
Poco classlarımızın Datannotion özelliklerini View tarafına yansıtma
özelliği ortadan kalkacak.örn..poco modelimiz MaxLength=20
attributes ini eklediğimizde bu direk
view e yansıyorken, View modelerimiz i kullandığımızdan artık bu durum
ortadan kalkacak.
Bu bahsettiğim durum ile mvc de karşılaşmıştım.Entity model ile UI
tarafanını ilişkisini tamamen koparıp view mdelleri kullanınca bu
sorunlar ortaya çıkmıştı.
Sizin fikirleriniz merak ediyorum
Seyhan Bakır
May 18, 2012, 7:44:38 AM5/18/12
to altdotne...@googlegroups.com
"Entity modellerimizi , UI(view) tarafında kullanmamak için view modellerimizi oluşturmalıyız" diye bir fikir üzerine birşey sormak istiyorum
+ tarafları
Entity modellerimizde kullanılan bazı propertyler view(UI) tarafında kullanılmıyor.Bu yüzden gereksiz yere bunları view katmanımıza taşımaya gerek yok
Entity modellerimizde yapacağımız bir değişiklik ile direk olarak view(UI) tarafının etkilenmesini engellemiş oluruz
- tarafları
Databaseden veri >>>entity model>>>view model şeklinde bir map/convert işlemi büyük datalarda performansı düşürebilir.
Emre Mert Asyalıoğlu
May 23, 2012, 12:29:47 PM5/23/12
to altdotne...@googlegroups.com
Selam,
View model zaten gorunum tarafinda ne kadar buyuk bir data olabilir ki kullaniciya gosterdigim sayfada? Bana gore mikro optimizasyon.
Asil soru gelistirme asamasinda hem view model hem model olusturma kaybi. Bunuda soyle cozuyorum her model icin validasyon class larimi ayiriyorum. Hem modele hem view modele bunu referans veriyor/vermiyor gerekirse ki view modelde gerekiyor cogunlukla eziyor yada ekliyorum.
Aslinda view model candir :) bence ama gerek yoksa da tipkisinin aynisi her modele view model de olusturmam.
Bu arada bir onceki cumleme istinaden ben de sunu sormak istiyorum. Entity modellerimizi neden view tarafinda kullanmamaliyiz gibi bir gorus var ? Arada bunuda aciklayabilirseniz arkadaslar sevinirim.
BlackBerry® Servisi ile gönderildi.
--
You received this message because you are subscribed to the Google Groups "altdotnetturkiye" group.
To post to this group, send email to altdotne...@googlegroups.com.
To unsubscribe from this group, send email to altdotnetturki...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altdotnetturkiye?hl=en.
View model zaten gorunum tarafinda ne kadar buyuk bir data olabilir ki kullaniciya gosterdigim sayfada? Bana gore mikro optimizasyon.
Asil soru gelistirme asamasinda hem view model hem model olusturma kaybi. Bunuda soyle cozuyorum her model icin validasyon class larimi ayiriyorum. Hem modele hem view modele bunu referans veriyor/vermiyor gerekirse ki view modelde gerekiyor cogunlukla eziyor yada ekliyorum.
Aslinda view model candir :) bence ama gerek yoksa da tipkisinin aynisi her modele view model de olusturmam.
Bu arada bir onceki cumleme istinaden ben de sunu sormak istiyorum. Entity modellerimizi neden view tarafinda kullanmamaliyiz gibi bir gorus var ? Arada bunuda aciklayabilirseniz arkadaslar sevinirim.
BlackBerry® Servisi ile gönderildi.
You received this message because you are subscribed to the Google Groups "altdotnetturkiye" group.
To post to this group, send email to altdotne...@googlegroups.com.
To unsubscribe from this group, send email to altdotnetturki...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altdotnetturkiye?hl=en.
Seyhan Bakır
May 28, 2012, 5:22:01 AM5/28/12
to altdotne...@googlegroups.com
" Entity modellerimizi neden view tarafinda kullanmamaliyiz gibi bir gorus var ? "
Açıkcası bende kullanıyorum.Hatta entity modellerim en alt assembly de ve tüm projeler bunu kullanıyor..
İleride data katmanı değişse bile yine aynı
entity modeller bind edilip kullanılabilir.
Açıkcası ben de bir sıkıntı görmüyorum.
Bir kaç olumsuzluğu olabilir ama bunları ortadan kaldırıcam diye projeyi kompleksleştirmeye gerek yok diye düşünüyorum.
23 Mayıs 2012 19:29 tarihinde Emre Mert Asyalıoğlu <easya...@gmail.com> yazdı:
Seyhan Bakır
May 28, 2012, 5:25:47 AM5/28/12
to altdotne...@googlegroups.com
"View model zaten gorunum tarafinda ne kadar buyuk bir data olabilir ki kullaniciya gosterdigim sayfada?"
Mobil cihazlarda problem olabiliyor.2000 row dan oluşan bir veri kümesini modellere convert edip sunmak ile direk datarow ile sunmak arasında
çok fark olabiliyor.
23 Mayıs 2012 19:29 tarihinde Emre Mert Asyalıoğlu <easya...@gmail.com> yazdı:
Selam,
Sidar Ok
May 28, 2012, 6:20:56 AM5/28/12
to altdotne...@googlegroups.com
Basit projelerde problem olmaz. Hatta basit projelerde ba$ka $ekil
yapilip abartmanin alemi yok.
Yalniz enterprise ciddiyetindeki projelerde bu bir kotu
design/architecture ornegidir. Nedeni basit, Senin UI da kullandigin
logic ve data database de kullandiginla, serviste kullandiginla ayni
degildir. UI da bir alanin kirmizi olmasi bir objede field olabilirken
cogu zaman bu domain layer icin veya database icin bir$ey ifade etmez.
Bu yuzden de kotu bir pratiktir.
Du$un mesela,domain tarafinda bir user account undan deposit
edebiliyor olsun. Bunu sen UI da kullanabiliyor ol. Ui tarafinda bunu
servislerle yapiyorsun diyelim her iyi cocuk gibi, cunku UI tarafi
business logic ya da domain kararlari vermiyor. Ama developer User a
tikladiginda Deposit metodu goruyor. Ne oldu ? Gitti oruc, ne
information hiding principle kaldi ne bi$ey.
Sadece data icin degil servis icin de aynisi gecerli. DTO kavraminin
ortaya cikmasinin temel sebebi budur.
2012/5/28 Seyhan Bakır <syh...@gmail.com>:
Sidar Ok
http://www.sidarok.com
http://www.twitter.com/sidarok
yapilip abartmanin alemi yok.
Yalniz enterprise ciddiyetindeki projelerde bu bir kotu
design/architecture ornegidir. Nedeni basit, Senin UI da kullandigin
logic ve data database de kullandiginla, serviste kullandiginla ayni
degildir. UI da bir alanin kirmizi olmasi bir objede field olabilirken
cogu zaman bu domain layer icin veya database icin bir$ey ifade etmez.
Bu yuzden de kotu bir pratiktir.
Du$un mesela,domain tarafinda bir user account undan deposit
edebiliyor olsun. Bunu sen UI da kullanabiliyor ol. Ui tarafinda bunu
servislerle yapiyorsun diyelim her iyi cocuk gibi, cunku UI tarafi
business logic ya da domain kararlari vermiyor. Ama developer User a
tikladiginda Deposit metodu goruyor. Ne oldu ? Gitti oruc, ne
information hiding principle kaldi ne bi$ey.
Sadece data icin degil servis icin de aynisi gecerli. DTO kavraminin
ortaya cikmasinin temel sebebi budur.
2012/5/28 Seyhan Bakır <syh...@gmail.com>:
http://www.sidarok.com
http://www.twitter.com/sidarok
emre eren
May 31, 2012, 4:49:56 PM5/31/12
to altdotne...@googlegroups.com
Selamlar; Hepimiz belli işler yapan programlar yazarız. Yine hepimiz öncelikli olarak programın beklenen işleri yapmasını hedefleriz. Ancak çoğu zaman programlar istenen noktaya ulaştıkları zaman "tamam bitti" denilerek bir köşeye konmaz. Ulaşılan nokta yeni beklentilerin oluşmasına neden olur ve programlar gelişmeye devam ederler. Bu nedenle bazılarımız programın yapabildiği şeyler kadar iyi bir yapısal tasarıma sahip olmasına da önem verirler. Ancak çoğu zaman aslında gelecekte nelerle karşılaşacağımızı da pek bilmeyiz. Genellikle yeni ve güzel fikirler aşama aşama gündeme gelirler ve bu fikirler çoğunlukla kodlaması bitmiş işler üzerinde değişiklikler yapmamızı gerektirir.
Sanırım Martin Fowler'ın bir kitabında "Shotgun Programming" diye bir tanımlama vardı. Bu programda bir değişiklik yapmak gerektiğinde programın birçok noktasında küçük küçük değişiklikler yapılmasını gerektiren bir durumu tarif eden güzel bir ifade ve tasarımla ilgili ciddi problemler olduğunun açık bir işareti. Belki yeni nesil adını hiç duymamıştır bile ama eskiden "Netscape Navigator" diye bir browser vardı ve resmen tüm piyasayı domine etmiş bir ürün olmasına rağmen "artık geliştirilmesinin mümkün olamayacağına" karar verilerek yaşamına son verildi. Küllerinden Firefox yeniden inşa edildi.
Bu tür ciddi yıkımlarla karşılaşmamanın en önemli şartı programlarımızı "geliştirilebilir" şekilde tasarlamak. Yani sadece belli özelliklerin çalışıyor olması yetmiyor. Bu özelliklerin nasıl tasarlandığı da önem arzediyor. Çok sık karşılaşılan tasarım problemlerine önerilen genel çözümlere Design Patterns yani tasarım kalıpları dendiğini biliyoruz. İşte MVVM'de böyle bir tasarım kalıbı. Bu tasarım kalıplarının tek başına faydasını tanımlamak zordur. Bu önerileri dikkate almanın faydasını ancak "ciddi değişiklikler" yapılması gerektiği noktada farkedebilirsiniz ve hangi durum için hangi tasarım kalıbının iyi işlediğini de ancak belli bir tecrübe edindikten sonra görebilirsiniz. MVVM, View tarafına Business Logic koymamayı ve View tarafını olabildiğince "Light" tutmayı öneren bir tasarım kalıbıdır. Bu tür öneriler tavsiye niteliğinden çıkıp bir tasarım kalıbına dönüşüyorsa bunun muhakkak bir sebebi vardır. Bu sebepleri belli kötü tecrübeleri yaşamış kişiler bilirler ama bunları henüz duvara çakılmamış kişilere anlatması çok zordur. Bu tıpkı hiç kanser vakası ile yüzleşmemiş bir kişiye sigaranın zararlarını anlatmak gibi birşey. Böyle ciddi durumlar yaşamamış kişiler için anlatılan her şey kulağa "o kadar da ciddi şeyler" değilmiş gibi gelir. Genellikle izah edilen durumlarla karşılaştığımızla bununla başedebileceğimizi düşünürüz.
Elbette projeniz MVVM tavisyelerine uymadığınız için herhangi bir problem yaşamayacağınız bir proje olabilir. Bu önerileri dikkate alıp almamak tamamen projeniz, kişisel tecrübeniz ve uzun vadede üzerinde çalıştığınız projeden beklentileriniz ile alakalı.
18 Mayıs 2012 Cuma 14:50:09 UTC+3 tarihinde sbakir yazdı:
Bu tür ciddi yıkımlarla karşılaşmamanın en önemli şartı programlarımızı "geliştirilebilir" şekilde tasarlamak. Yani sadece belli özelliklerin çalışıyor olması yetmiyor. Bu özelliklerin nasıl tasarlandığı da önem arzediyor. Çok sık karşılaşılan tasarım problemlerine önerilen genel çözümlere Design Patterns yani tasarım kalıpları dendiğini biliyoruz. İşte MVVM'de böyle bir tasarım kalıbı. Bu tasarım kalıplarının tek başına faydasını tanımlamak zordur. Bu önerileri dikkate almanın faydasını ancak "ciddi değişiklikler" yapılması gerektiği noktada farkedebilirsiniz ve hangi durum için hangi tasarım kalıbının iyi işlediğini de ancak belli bir tecrübe edindikten sonra görebilirsiniz. MVVM, View tarafına Business Logic koymamayı ve View tarafını olabildiğince "Light" tutmayı öneren bir tasarım kalıbıdır. Bu tür öneriler tavsiye niteliğinden çıkıp bir tasarım kalıbına dönüşüyorsa bunun muhakkak bir sebebi vardır. Bu sebepleri belli kötü tecrübeleri yaşamış kişiler bilirler ama bunları henüz duvara çakılmamış kişilere anlatması çok zordur. Bu tıpkı hiç kanser vakası ile yüzleşmemiş bir kişiye sigaranın zararlarını anlatmak gibi birşey. Böyle ciddi durumlar yaşamamış kişiler için anlatılan her şey kulağa "o kadar da ciddi şeyler" değilmiş gibi gelir. Genellikle izah edilen durumlarla karşılaştığımızla bununla başedebileceğimizi düşünürüz.
Elbette projeniz MVVM tavisyelerine uymadığınız için herhangi bir problem yaşamayacağınız bir proje olabilir. Bu önerileri dikkate alıp almamak tamamen projeniz, kişisel tecrübeniz ve uzun vadede üzerinde çalıştığınız projeden beklentileriniz ile alakalı.
Okuduğunuz için teşekkürler...
18 Mayıs 2012 Cuma 14:50:09 UTC+3 tarihinde sbakir yazdı:
Muzaffer Anıl KABAN
May 31, 2012, 6:09:15 PM5/31/12
to altdotne...@googlegroups.com
Haklisin :)
31 May 2012 23:49 tarihinde "emre eren" <emre...@gmail.com> yazdı:
--
You received this message because you are subscribed to the Google Groups "altdotnetturkiye" group.
To view this discussion on the web visit https://groups.google.com/d/msg/altdotnetturkiye/-/AB2_NJ7GGzgJ.
Berat Bilgin
Jun 1, 2012, 3:34:48 AM6/1/12
to altdotne...@googlegroups.com
Kesinlikle...
--
Berat Bilgin
1 Haziran 2012 00:09 tarihinde Muzaffer Anıl KABAN <muzaff...@gmail.com> yazdı:
--
Berat Bilgin
Mehmet Erdanışman
Jun 1, 2012, 3:37:44 AM6/1/12
to altdotne...@googlegroups.com
Zafer Çelenk
Jun 1, 2012, 8:27:09 AM6/1/12
to altdotne...@googlegroups.com
Emre'nin yaz�s�n� severek okudum, eline sa�l�k bencede �ok g�zel bir
yaz� olmu�. Di�er arkada�lar gibi bende bu yaz�n�n hakl� oldu�unu
d���n�yorum ama b�yle d���nmenin �ok anlaml� oldu�unu sanm�yorum.
M�him olan bu d���nceyi kurdu�umuz sistemler �zerine uygulayabilmek.
Ben �ok b�y�k projelerde �al��mad�m, �imdi �al��t���m yerde �al��t���m �irket i�in k���k entegrasyon projeleri geli�tiriyorum. M�mk�n mertebe �ok katmanl� mimari ve s�re�leri birbirinden ay�rmak ad�na kendimce bir tak�m y�ntemler kullan�yordum. Burayla ve sizlerle tan��t�ktan sonra bu konular� daha s�k� takip etmeye ve uygulamaya �al���yorum.
Ancak neticede bunun sadece kod odakl� oldu�unu d���nm�yorum aksine bu felsefeyi ve d���nce yap�s�n�n anlay�p i�selle�tirebilmek bence �ok daha �nemli, e�er geli�tirici bunu yapabilirse zaten ad� MVC ve MVVM olan bir yakla��m yerine kendi yakla��m�n� da pekala olu�turabilir. Bildi�im kadar�yla �stanbulda bir araya gelip toplant�lar yap�l�yor Ankara'dada b�yle organizasyonlar var m�? Kat�lmay�, tan��may� ve sohbet etmeyi �ok isterdim.
Ben �ok b�y�k projelerde �al��mad�m, �imdi �al��t���m yerde �al��t���m �irket i�in k���k entegrasyon projeleri geli�tiriyorum. M�mk�n mertebe �ok katmanl� mimari ve s�re�leri birbirinden ay�rmak ad�na kendimce bir tak�m y�ntemler kullan�yordum. Burayla ve sizlerle tan��t�ktan sonra bu konular� daha s�k� takip etmeye ve uygulamaya �al���yorum.
Ancak neticede bunun sadece kod odakl� oldu�unu d���nm�yorum aksine bu felsefeyi ve d���nce yap�s�n�n anlay�p i�selle�tirebilmek bence �ok daha �nemli, e�er geli�tirici bunu yapabilirse zaten ad� MVC ve MVVM olan bir yakla��m yerine kendi yakla��m�n� da pekala olu�turabilir. Bildi�im kadar�yla �stanbulda bir araya gelip toplant�lar yap�l�yor Ankara'dada b�yle organizasyonlar var m�? Kat�lmay�, tan��may� ve sohbet etmeyi �ok isterdim.
Reply all
Reply to author
Forward
0 new messages