Re: NHibernate & Entity Framework (ado.net 3.5 ile) Karşılaştırması

[AYDIN ÜNLÜ]

Benim sormak istediğim Linq to SQL ile Entity Framework' ün tek farkı, EF' nin tam bir ORM acagı olmak adına birden fazla DBMS' i desteklemesimidir ?

Kısa bir süre önce bende yeni bir projeye başladım ve ilk şu anda Linq to Sql kullanmayı planlıyorum. Bugün de biraz EF'ye baktım netten ama linq to sql ile arasında bariz bir fark göremedim. NHibarnate ile arasındaki farklara bakarken bunada parantez içinde değinirseniz çok sevinirim...

09 Mart 2009 Pazartesi 02:50 tarihinde HÜNKAR <hayrull...@gmail.com> yazdı:

aldığım adreside eklimde ordanda bakabilir arkadaşlar

http://ihsanindefteri.blogspot.com/2009/02/nhibernate-entity-framework-adonet-35.html

--
Mehmet Aydın Ünlü (Yazılım Uzmanı)
Etiya - 0 212 356 10 25 - 26
0555  464  41  85
http://aydinunlu.blogspot.com

[hayrullah güven]

Benim bildiğim kadarıyla sintax olarak okadar bir değişiklik söz konusu değil. Bana göre örneğin en büyük farkı nesnelerin eşleştirilmesi linqtosql deki gibi kod içerisinden değilde xml den yapılıyor. Buda programıcya daha esnek ve manevra kabiliyeti daha fazla olan bir yapı oluştrumasına izin veriyor. Kişisel düşüncem tabi ki bunlar:)

09 Mart 2009 Pazartesi 12:27 tarihinde AYDIN ÜNLÜ <aydin...@gmail.com> yazdı:

[Serhat Özgel]

Microsoft .net 4.0'dan itibaren tavsiye edecekleri çözümün EF olacağını duyurdu. Ling to sql'i desteklemeye devam edecekler ama asıl odakları ef olacak. EF'nin bir sonraki versiyonunda testability, lazy load, poco gibi konularda developer'ların şikayetlerine cevap verip bu alanlardaki sıkıntıları gidereceklerini duyurdular. Dolayısıyla bu linq to sql ve ef arasında kalındıysa ef ile devam etmek gerekli.

2009/3/9 hayrullah güven <hayrull...@gmail.com>

[Tuna Toksoz]

Tamamen sacmalik oldugunu dusunmeye basladim bu yazinin.

1. Visual Studio Entegrasyonu -> Bakiniz Active Writer
Ayrica bakiniz Domain Drives DB

2. Kriter : Kod generation : Umrumda bile degil. Bakiniz ustteki durum.

3. Kriter : Generic / third party ?
Monorail -> ASP.NET MVC
NH -> EF
Lucene.NET -> Velocity
Windsor/Spring->Unity

dersem sanirim yeterli olur. Bunlarin karsilastirmasini nette bulabilirsiniz. Ayrica acik kaynak kod olmasi dolayisiyla kendim gelistirmem mumkun, bunu yaparken da en iyi pratikleri ogrenme sansim yuksek, microsoftta bi halt yapamam..

4. Kriter : sql query tuning: Projections, result transformers and upcoming Artorius

5. Kriter : DB bağımsız çalışabilme (amaçlanan oracle ve mssql)
Sql2008 de listede var. Ayrica SPATIAL konusunda dahiyane Postgreyi de sorunsuz destekliyor. Biri spatial mi dedi ?

6. Kriter : build esnasinda olasi kod hatalarini görüntüleyebilme yetenegi.
WTF? Unit testler guzeldir, ayrica Fluent NH cok cok daha guzel. Microsoftun wizardinin eline verebilecek kadar guclu toplam 20 satirda tum veritabaninizi iyi kotu modelleyebileceginiz convention destegi de cabasi.

7. Kriter : destekler, çikarilan bugfixler / bizim düzeltme olanagimiz
Bugi olan varsa soylesin ben bakacam soz.
Ayrica " Microsoft, .net Framework içinden aşağıdaki librarylerin source koduna erişmemize ve değiştirmemize olanak sağlıyor." Yalan.


15. Entity framework’e geçiş durumunda zaman kazandırma ; hql e karşılık linq yazmanın zaman kazandıracağı ortada. nHibernate de kod generator kullanmadığımızı varsayarsak biçok şeyi entity framework bizim için generate ediyor. Ancak bu durumlarda ne kadar zaman kazandıracağını hesaplamak pek mümkün görünmüyor

Yeter sikildim bu linq olayindan az daha sikin disinizi.

b. nHibernate ;
i. xml de lazy=true / false ile yapılabiliyor. Code behind’da nasıl yapıldığını anlamadım.

Codebehindda her turlu sorguya karsiyim. Fakat illa istiyorsan lazy yi true yapip sorgu yaparken fetchi acabilirsin.

16. NH kullanan projeler

EF kullananlardan cok daha fazla. Ayrica vote of no confidence i da okumanizi tavsiye ederim


Yoruldum.





Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/9 tragedy <hayrull...@gmail.com>

Çoğu arkadaşımız projelerinde Nhibernate mi yoksa Entity Framework mu
tercih etsem diye bir karar noktasına gelir. İnterntte gezerken
bunları kaşılaştıran bir yazı buldum. Hep birlikte okuyalım diye
buraya ekliyorum. Ve tabiki her zamanki gib tartışacaz:)

Nhibernate ve ADO.NET Entity Framework Karşılaştırması
1. Kriter : Visual studio entegrasyonu
a. Entity Framework Visual studio entegrasyonu ve araçları;
Visual studio 2008 sp1 kullanarak, db deki tablolar objelerle map
edilebilir, bunlar arasındaki ilişkiler entity designer kullanılarak
kurulabilir, değiştirilebilir, objectlerden tablolar, tablolardan
objectler generate edilebilir. Oluşturulan objeler serialize
edilebilir.
Model browser; oluşturulan modellere ait detayları görüntüler,
Mapping details, oluşturulan modellerin db tablolarıyla olan
eşleşmelerini görüntüler ve değiştirmemize yardımcı olur.
Entity Data Model Designer; Oluşturulan modellerin arasındaki
ilişkileri düzenlememizi, yeni ilişki atayabilmemizi, başka bir
classdan inherit edebilmemizi, yeni scaler proprerty oluşturabilmemizi
sağlar.
Entity Wizard Data Model Wizard; http://msdn.microsoft.com/en-us/library/bb399247.aspx
linkinde mevcut.
DB deki Table'larla map edildiği için düzgün yapılmış bir db
tasarımıyla foreign key lere bakarak uygun ilişkileri kurmamızı
sağlar. Bu ilişkiler class diyagramı halinde görüntülenebilir.
b. Nhibernate Vusial studio entegrasyonu:
Nhibernate de hbm.xml dosyaları oluşturulduktan sonra vs2008'in xml
editörü kullanılarak kolayca düzenlenebilir. Oluşturulan classlar
class view ile rahatlıkla görüntülenebilir. Nhybernate'e başka bir
third party kullanmadan VS2008 ile entegre olduğu söylenemez. Ancak
nHibernate LINQ ile de kullanılabilir. Detaylar :
http://www.hookedonlinq.com/LINQToNHibernate.ashx
http://ayende.com/Blog/archive/2007/03/17/Implementing-Linq-for-NHibernate-A-How-To-Guide--Part.aspx
adreslerinde mevcut.

2. Kriter : Kod generation
a. Entity Framework Kod generation ;
EF kullanmak için oluşturulması gerken şey edmx dosyasının
oluşturulması. Eğer edmx dosya boyutunun büyüme durumu sıkıntı
yaratırsa (Bu konuda bi sorun yaşandığını okumadım ama olası durumları
göz önünde bulunduruyorum) Projeye ait bütün tablolar tek bir entity
data model içinde oluşturulabillir, yada modül halde gruplanarak
oluşturulabilir. edmx generate etmenin birden fazla yolu var,
tabloları sürüklemek yada komut satırından generate etmek gibi.
Ayrıntılar için (http://blogs.msdn.com/dsimmons/pages/entity-framework-
faq.aspx ) - sık sorulan sorular.
b. nHibernate kod generation
MyGeneration, Codes gibi araçlar kullanılarak .net code generation
yapılabilir. nHibernate'in kendi kod generater'ı da var. Hibernate
Extensions package içinde mevcut ancak java için kod generate ediyor.
Bu generator'ın xml kısmı kullanılabilir. Kaynak : nHibernate
reference guide.
3. Kriter : Generic / third party ?
a. Entity framework microsoft tarafından yazılmış ve yine microsoft
tarafından desteği verilen bir araç. Ek bir uygulama gerekmiyor.
Desteğini microsftun veriyor olması özelliğinin bize güven vermesi
gerekir.
b. nHibernate açık kaynak bir araç ancak desteği microsoft tarafından
sağlanmıyor . Web sitesinde :"Copyright 2006, Red Hat Middleware, LLC.
All rights reserved. JBoss and Hibernate are registered trademarks and
servicemarks of Red Hat, Inc." ifadesi mevcut. Burdan redhat inc'ye
ait olduğu kanısına varabiliriz. Açık kaynak olması avantaj, ancak
açık kaynak projeleri customize edebilmek için proje yapısının büyük
bölümünü öğrenmemiz gerekir ki farkında olmadan projedeki başka
yerleri bozma ihtimalimiz de var.
4. Kriter : sql query tuning
a. Entity framework LINQ to Entity framework kullanırsak objelerin
getirmek istediğimiz kolonlarına ait veriye ulaşabiliyoruz. Bu sayede
gereksiz veri çekme işleminden kurtulabiliriz. Bu durumda da sorun
çıkarısa linq to sql'i de kullanabiliriz.
b. nHibernate
HQL ile sorgu yazarsak query tuning mümkün, ancak objelerin sadece
isediğimiz property'lerini doldurmamız durumunu desteklemiyor.

5. Kriter : DB bağımsız çalışabilme (amaçlanan oracle ve mssql)
a. Entity framework SQL 2005 / 2008, Oracle, MySQL ve PostgreSQLsp1
güncellemesiyle sql server 2008 deki yeni fieldtype'lara da destek
veriyor.
b. nHibernatesql 2008 listede yok ama başka bi yazda sql2008
DB2 7.1, 7.2, 8.1, 9.1
Microsoft SQL Server 2000
Sybase 12.5 (JConnect 5.5)
MySQL 3.23, 4.0, 4.1, 5.0
PostgreSQL 7.1.2, 7.2, 7.3, 7.4, 8.0, 8.1
TimesTen 5.1, 6.0
HypersonicSQL 1.61, 1.7.0, 1.7.2, 1.7.3, 1.8
SAP DB 7.3
InterSystems Cache' 2007.1
Veri tabanlarına destek verdiğini söylüyor.
Hibernate'in sitesinde aşağıdaki db versiyonlarıyla da test edildiğine
dair bilgi yer almakta.

Apache Derby
HP NonStop SQL/MX 2.0 (requires Dialect from HP)
Firebird (1.5 with JayBird 1.01 tested)
FrontBase
Informix
Ingres
Interbase (6.0.1 tested)
Mckoi SQL
Pointbase Embedded (4.3 tested)
Progress 9
Microsoft Access version from 95, 97, 2000, XP, 2002, to 2003
(requires Dialect from HXTT)
Corel Paradox version from 3.0, 3.5, 4.x, 5.x, 7.x to 11.x (requires
Dialect from HXTT)
flat text , CSV file, TSV file, fixed-length, and variable-length
binary file (requires Dialect from HXTT)
Xbase database (dbase, Visual DBASE, SIx Driver, SoftC, Codebase,
Clipper, Foxbase, Foxpro, VFP(3.0,5.0,7.0,8.0,9.0, 10), xHarbour,
Halcyon, Apollo, Goldmine, and BDE) (requires Dialect from HXTT)
Microsoft Excel version from 5.0, 95, 97, 98, 2000, 2001, 2002, 2003,
to 2004 (requires Dialect from HXTT)
6. Kriter : build esnasinda olasi kod hatalarini görüntüleyebilme
yetenegi.
a. Entity frameworkEntity'ler db tablolarından generate edildiğinden
mapping'i biliyoruz ve bu mappinge ait bilgileri kod yazarkende
kullanabiliyoruz. Projeyi bir kere build ettiğimizde build - time'da
hatayı görebiliriz, sorguları string ifadeler içinde yazmadığımız
sürece. Typeddatasetlerde olduğu gibi entity property'lerinden LINQ
ile sorgulama yaptığımız için db objectlerindeki hataları projeyi
publish etmeden yada production a almadan önce görebilme imkanımız
var. Ayrıca linq sorglama dili intellisense desteği olan bir dil.
b. nHibernate;HQL'de intellisense desteği yok ve LINQ gibi dile
entegre değil. HQL yazmak yada test etmek için stabil çalışan bir
aracı şimdilik bulamadık. Sorguları oluştururken string ifadeler
kullanırsak build esnasında bu ifadelerin içindeki hataları
görüntüleyemeyebiliriz. Kodda ilgili yere gelinceye kadar projede hata
yokmuş gibi çalışabilir ve ilgili yere gelince hata alabiliriz. Sorgu
kriteri oluşturmada linq yada query generator adlı aracı
kullanabiliriz.
http://cromwellhaus.com/blogs/ryanc/archive/2007/11/19/nhibernate-query-generator-with-visual-studio-2008.aspx
(query generator)
http://www.hookedonlinq.com/LINQToNHibernate.ashx (LINQ to nHibernate)
7. Kriter : destekler, çikarilan bugfixler / bizim düzeltme olanagimiz
a. Entity framework;
i. Microsoft, .net Framework içinden aşağıdaki librarylerin source
koduna erişmemize ve değiştirmemize olanak sağlıyor. .NET Base Class
Kütüphanaleri (System, System.CodeDom, system.Collections,
System.ComponentModel, System.Diagnostics, System.Drawing,
System.Globalization, System.IO, System.Net, System.Reflection,
System.Runtime, System.Security, System.Text, System.Threading, vs).
ASP.NET (System.Web, System.Web.Extensions)
Windows Forms (System.Windows.Forms) Windows Presentation Foundation
(System.Windows) ADO.NET ve XML (System.Data ve System.Xml)
Çok yakında diğer sınıfların da zaman içerisinde paylaşıma açılacağı
duyrulmuş.

Ayrıntılar için ;
http://daron.yondem.com/tr/PermaLink.aspx?guid=d23bbb25-5fdf-4599-824a-cb8f8931fa3d
Desteğini Microsoft veriyor. Sp1 de birçok bug giderilmiş.

b. nHybernate
i. Tüm proje açık kaynak. Son versiyonun release date'i 2008-09-29
8. Kriter : caching,
a. nHibernate
i. First level cache, daha önce sorgulanan yada insert edilen
verilerin tekrar dbden sorgulanmasını engeller. Yararlı bir yapı.
ii. Second level cache; true key'ini configuration dosyasına
ekleyerek, key'ini de entity map dosyamıza ekleyerek kullanabiliriz.
b. Entity framework
i. Caching'i biz yönetiyoruz.
9. Kriter : auditing,
a. nHibernate
i. IInterceptor interface'I otomatik olarak save,update,delete yada
load durumunda bazı bilgileri tutuyor. (auditing bilgisinin database'e
yazılmasıyla ilgili bişey göremedim)
b. Entity Framework;
i. Her entity'ye ait olan EntityState property'sini kullanarak entity
durumunu öğrenebiliriz, bu durumlara ait değişikliği yönetebiliriz.
(Detaylar http://blogs.msdn.com/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx
adresinde)
ii. Auditing ile ilgili bir soruya verilmiş bir cevap :
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/b906a246-8bec-4d07-83b1-4ce6a91adc95/

10. Kriter : Concurrency,
a. entity framework
i. http://msdn.microsoft.com/en-us/library/bb738618.aspx adresinde
managing concurrency adlı bir döküman var.
b. nHibernate
i. Reference guide'da Optimistic concurrency control başlığında 10.
Chapter da açıklanmış.
11. Kriter : Transactions,
a. nHibernate
i. reference guide Transactions başlığında 10. Chapter da açıklanmış.
b. Entity framework
i. http://msdn.microsoft.com/en-us/library/bb738540.aspx adresinde
açıklanmış
c.
12. Kriter : query api
a. nHibernate
i. HQL ve criterias.add ile kriter oluşturma
ii. Ayrıca LINQ to nHibernate ile ilgili ayrıntılar :
http://www.hookedonlinq.com/LINQToNHibernate.ashx
b. Entity framework
i. Entity SQL, LINQ Queries, LINQ to Entities.
ii. Detaylar için: http://blogs.msdn.com/diego/archive/2007/11/11/choosing-an-entity-framework-api.aspx
13. Kriter : teknolojinin olgunlugu
a. nHibernate 1.0 release date : Ekim 12, 2005, son release date'i:
2008-09-29
b. Entity framework release date: 11 Ağustos 2008 (framework 3.5 sp1
ile birlikte)
14. Spatial Data Type Desteği
a. Nhibernate için ;
i. http://nhforge.org/wikis/spatial/introduction.aspx linkinde mevcut.
ii. NHibernate.Spatial, spatial extensions for NHibernate, allows you
to connect NHibernate to a spatially enabled database and manipulate
geometries in HQL or in .NET code using NetTopologySuite, providing
you with a fully integrated GIS programming experience.
iii. http://www.codeplex.com/NHibernateSpatial/Thread/List.aspx
linkindede bazı bilgiler mevcut.
b. Entity framework için ;
i. Entity framework spatial data type'ı bir User Defined Type
olduğudan şu anki sürümünde doğrudan desteklemiyor. Ancak
http://social.msdn.microsoft.com/forums/en-US/adodotnetentityframework/thread/b0ac34d7-91de-4af9-8064-af4625fd6a25/
linkinde binary yada image olarak okunduktan sonar partial class
kullanarak SQLGeography sınıfının kullanılabildiği yazıyor.
15. Entity framework'e geçiş durumunda zaman kazandırma ; hql e
karşılık linq yazmanın zaman kazandıracağı ortada. nHibernate de kod
generator kullanmadığımızı varsayarsak biçok şeyi entity framework
bizim için generate ediyor. Ancak bu durumlarda ne kadar zaman
kazandıracağını hesaplamak pek mümkün görünmüyor
16. Lazy loading
a. Entity framework;
i. Varsayılan olarak lazy load aktif değil, bu işlem için çok fazla
kod yazmak gerekmiyor, Örnek için:
http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx
b. nHibernate ;
i. xml de lazy=true / false ile yapılabiliyor. Code behind'da nasıl
yapıldığını anlamadım.
17. Diğer ORM Araçları
NET Persistence,BBADataObjects ,DataObjects.NET ,Data Tier Modeler
for .NET ,DotNorm ,Eldorado.NET ,Enterprise Core Objects
(ECO(tm)) ,Entity Broker ,eXpress ,ersistent Objects
for .NET ,FastObjects.NET ,JC Persistent Framework ,LLBLGen
Pro ,ModelWorks ,Nhibernate ,Nolics.NET ,Norm ,Norpheme ,ObjectBroker ,ObjectSpaces ,ObjectSpark ,Objectz.NET ,OJB.NET ,OPF.Net
(Object Persistent Framework) ,ORM.NET ,Pragmatier Data Tier
Builder ,RapTier ,Sisyphus Persistence
Framework ,TierDeveloper ,Bob.NET ,ObjectPersistor.NET ,Genome


18. Entity framework başarılı projeler :
Türkiye'den bulduğum www.ttnetoyun.com.tr . Proje hakkında yazdığım
mail ve verilen cevap şöyle;

Merhabalar, Adım ihsan akın, bir şirkette yeni bi projeye başlamak
için hazırlık sürecindeyiz. entity framework'ü kullanmak istiyoruz
ancak daha önce yaşayan bi projedeki sorunlarının ne olduğunu merak
ediyorum. Bu konuda bi açıklama yapabilir misiniz? en sık hangi
sorunla karşılaştınız, nasıl çözdünüz? framework 3.5 sp1 ile birlikte
karşılaştığınız sorunlar yada bug'lar giderildimi? biraz da proje
büyüklüğünden ve yapısından bahsederseniz çok sevinirim. şimdiden
teşekkürler.

Merhaba, Açıkcası yazıda da değindiğim gibi ORM çok hakim olduğum bir
konu değil. Yazılım mimarımızın önerisiyle bu işe girdik ve EF bizi
yarı yolda bırakmadı. EF'yi kullandığımız TTNetOyun projesi şu an
canlıya alındı ve hiçbir sorun yaşatmadan çalışıyor, ttnetmüzik ve
ttnetvideo ile ortak bir login sistemi geliştirildi yine EF
kullanılarak onda da bir sorun yok. Şahsen bir görüş bildiremem ama,
TTNet gibi büyük ve milyonlarca kullanıcısı olan bir şirketin
projelerinde Innova olarak EF yi kullanmakta bir sakınca görmüyor
yazılım mimarlarımız. Yaşadığımız problemler ilk zamanlar internette
yeterli kaynak olmamasından kaynaklanıyordu, öğrenme sürecinde
zorlandık. Bir de daha yeni olduğu için linq to sql in desteklediği
her şeyi linq to entity henüz desteklemiyor, ama bu sorun bizim
önümüzü ciddi manada hiç kesmedi. EF sp1 ile zaten betadan kurtuldu,
dizaynırında ufak can sıkan buglar var en çok gözümüze çarpan ama bir
sonraki sürümde bunları da gidereceklerini umuyoruz.Daha fazla bilgi
vermek isterdim ama benim de bilgim henüz kısıtlı EF hakkında, umarım
yardımcı olabilmişimdir.




MSDN Forums 'a yazdığım post ve cevabı;
Dear all,
We are preparing for a new project. This project will be database
driven web application. We have make a decision about using ORM. We
have questions about "is Entity framework ready for large project?".
Anyone use entity framework in a real project? if you ask what is a
big project, project may have About 1000 users. Our another option is
using nHibernate for ORM. Anyone compare those? I found a project
developed in Turkey. but its not enought for me.
Thanks in advance.
Ihsan
Cevap :
I'm not sure the number of users is that relevant, maybe you mean
number of concurrent users, and if so, it matters if you refer to 1000
concurrent users that works in client-server mode (application to db
via EF) or are you talking about smart clients that uses services to
access the db.
Our application doesn't service 1000 users, but it does hold a
considerably large model (a few hundred entity types) and we've been
working with EF for over a year - we have written a lot of code to
handle EF through services, but the EF core remained intact and
working quite well.


Elimizde nHibernate reference guide var ancak böyle bi klavuz kayıtlı
olmadığından entity framework ile ilgili kaynaklara aşağıdaki
linklerden erişebiliriz.
ADO.NET Entity framework Overview http://msdn.microsoft.com/en-us/library/bb399572.aspx
Entity framework programming guide : http://msdn.microsoft.com/en-us/library/bb738553.aspx
Feature Reference (Entity Framework) http://msdn.microsoft.com/en-us/library/bb738623.aspx
Introduction to LINQ http://msdn.microsoft.com/en-us/library/bb397926.aspx

Sınırlı kaynağımız olduğu gibi bi durumda artık görünmüyor sadece msdn
den gelen sonuçlarına http://www.google.com.tr/search?hl=tr&q=entity+framework+site%3Asocial.msdn.microsoft.com&meta=
linkinden ulaşabiliriz.

[Tuna Toksoz]

Ayrica lutfen kimse bana XML esnekliktir demesin.

[Tuna Toksoz]

Velocity -> Memcached olacakti.

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/9 Tuna Toksoz <teh...@gmail.com>

[Gökhan Altınören]

Benim ActiveWriter hevesim azalmasaydi gosterirdim ben EF team'ine hanyayi konyayi ama iste... neyse :)

Tuna, MS urunlerinin daha bilinir olmasi ya da rakipleri hakkainda yanlis bilinirlik cok normal, hep boyleydi hep de boyle olacak. Cok fazla kizmak ya da tepki gostermek gereksiz bence, bilgiyi arastirip bulmayi bilen ve seven adam kendisi icin hangisi iyiyse ona ulasir zaten MS urunu ya da baskasi, oteki su yapida zaten NH kullanamaz ve MS urunu onun icin zaten dogru urundur. Takma kafana.

Eleman 1. ve 2. maddelerde arastirma yapmis ve ActiveWriter'in var oldugu bilgisine ulasamamis bile. Simdi bu eleman NH kullanmaya kalksa ya mapping'de ya query'de bir yerde takilir ve devam edemez zaten. O yuzden bence kendi icin en dogru karari vermis ve projesine fistik gibi baslamis. En dogru teknoloji olayina kisiye gore en dogru teknoloji olarak baktigimizde super haraket yapmis oluyor. Gun gelir devran doner, belki siki bi NH kullanicisi olur belli olmaz. Sonucta EF'un de insalarin isini gorebilecegi projeler de mutlaka olacak.

2009/3/9 Tuna Toksoz <teh...@gmail.com>

[Oğuz Kurumlu]

"Simdi bu eleman NH kullanmaya kalksa ya mapping'de ya query'de bir yerde takilir ve devam edemez zaten. "

Bu cumleye katılıyorum. Hatta bu cumleyi daha onceden farkedip zararını gören biriyim ve bazı şeyleri sadece anlayabilicek insanlara anlatıyorum. Vizyonu olmayan insanlara anlatmamaya calisiyorum Tuna ;)

Konuyu saptırdıysam ozur dilerim.

2009/3/9 Gökhan Altınören <gok...@altinoren.com>

[Tarik Kranda]

Bu 18. maddedeki e-postaya kim cevap vermis acaba bizim takımdan:) Her iki ürünü de kullanan, az cok bilen birisi olarak her ikisi de surekli gelistirme ve bakım asamasında olan urunler. Birisi daha yeni ama digeri de binlerce projede kullanılmıs, acık kaynak koduyla kimbilir belki EF ekibine fikir vermis olan bir proje ve insanlıga katkısı buyuk:)

Bahsi gecen kıyaslamada EF direkt bir MS Team oldugu icin default avatajlara sahip NHibernate gelistiricileri karsısında. VS Entegrasyonu elbette ekstra bir bilesen yuklemeyi gerektirmeyecektir. Bundan daha dogal ne olabilir:) Ya da adamlar bunu butun gun maas alarak bir takım halinde gelistirirken, diger proje bir takım gonullu katılımcıların destegi ile yuruyorken ve onunuzde hali hazırda calısan bircok acık kaynak kodlu ORM aracı var iken hızla diger ozellikleri build edebilirsiniz.

Kısacası demek istedigim MS kendisi bir ürün cıkarttıgı zaman bu kıyaslamaları fazlasıyla yaparak ve goz onune getirerek hızlı girisler yapıyor sektore. Bu demek degildir ki diger urunler bırakılmalı, buna gecilmeli. Hersey olculmeli tartılmalı, orneklerine bakılmalı.

Su anda bizim DB istatistiklerimizde EF nin query stats ları daha yuksek NHibernate e gore. Bunlar farklı projeler ve yazılan query amacına ne kadar mantıklı hizmet ediyordur tartısılır tabiki fakat, NHibernate biraz daha performans lı gibi gorunuyor son kalemde gozume. Detaylı incelemek lazım dmv leri. Aynı projeler icin.

İyi çalısmalar.

09 Mart 2009 Pazartesi 17:17 tarihinde Oğuz Kurumlu <oguz.k...@gmail.com> yazdı:

[Pamir Erdem]

Merhaba

Bir projede NH ,EF ya da normal direk SqlConnectionlarla erişmenin her projede tradeoff una göre seçimi vardır. Şimid birine günlerce süren toplantılardan sonra performans testlerinden sonra takıma uygunluğuna göre sadece küçük bir posta karşılık vizyonsuzlar demek haksızlık hatta saygısızlık olacaktır. Vizyon dediğiniz NH kullanmadım EF kullandım her ikisini de sevmedim kendiminkini yazdım 

visual studio biri entegre diğeri değil vizyon ise vizyon kelimesini anlamını daraltıyor olacaksınız bunları bilip anlatmak vizyondan öte araştırmadır bunu yazmaksa kendi deneyimidir insanların. Bu tip postlarda eski Linux vs MS tartışmalarına dönmemesini ve yazılanların dikkatlice yazılmasını hiç bir kurum kuruluş ve kişiyi itham altında bırakılmamasını rica ediyorum.

Saygılarımla

Pamir

[Tarik Kranda]

Vizyon lafı nerde gecti Pamir:) Ben atlamısım:))

09 Mart 2009 Pazartesi 17:38 tarihinde Pamir Erdem <pamir...@gmail.com> yazdı:

[Oğuz Kurumlu]

"Bir projede NH ,EF ya da normal direk SqlConnectionlarla erişmenin her projede tradeoff una göre seçimi vardır."

Sizin için doğru olabilir. Fakat üzerinden cok fazla transaction un geçtiği nakit akışının takip edildiği bankacılık uygulamasında nhibernate kullanıldı. Tabi biraz kullanmayı bilmekle alakalı bişi var bu noktada. NH ile saf veri cekip. Statik verileri client da cache liyip yine client ta nquery joiniyle viewmodelleri olusturmak gibi, aynı anda 3 thread le sorgu gonderip sonuclarını beklemek gibi falan. Oldukca hızlı calisiyor.

Vizyondan kastım o değil. Kafasını kuma gömenlerle tunaların doğaların farkı...

"Simdi bu eleman NH kullanmaya kalksa ya mapping'de ya query'de bir yerde takilir ve devam edemez zaten. "

Su durumlara dusup beni delirten insanlar. Onlarla ugrasmıyorum. Ugrasmak zorunda değilim. Eğer nh nin artılarını anlattıgımda onun için hiç bişi ifade etmiyosa. Vizyonu yoktur evet. Aynı dilden konusmuyoruzdur.

2009/3/9 Tarik Kranda <tarik...@gmail.com>

[Tarik Kranda]

Birisi bana gercekten ORM in ciddi faydalrından birkac kuple birsey soyleyebilir mi acaba?
ORM kullanmalıyım cunku seklinde. ORM kullanan arkadaslar 3 madde seklinde en azından en onemli gorduklerinden bahsedebilirler mi?
ORM ile code generation ı karıstırmadan elbette.

Neler cıkacak acaba?

09 Mart 2009 Pazartesi 18:12 tarihinde Oğuz Kurumlu <oguz.k...@gmail.com> yazdı:

[Tuna Toksoz]

EF kullanmaktaki amaciniz neydi?

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/9 Tarik Kranda <tarik...@gmail.com>

[Tarik Kranda]

Tamamiyle zaman kazancı. Aynı neden NHibernate kullanırken de karısmıza cıkan nedendi. Burada is biraz da ORM den cıkıp, gene code generation a dogru kayıyor ama sonuc olarak temel neden bu idi. Performans saglayacagını dusunmedik. Nitekim calıstıgımız platform .net oldugu icin zaten ORM tollarının kullandıgı performans saglayıcı etmenlerde cesitli sınıf kutuphaneleri altında elimizde vardı. Atıyorum cacheleme olsun, baska birsey olsun.

Diger taraftan nesneye yonelik bakıs acısı ile projeyi degerlendirmek ve gelistiricilere asina oldukları bir ortam mı saglamıs olduk? Aslına bakarsanız bu da tam olarak boyle degil. Bunu neye dayanarak soyluyorum gelistiriciler NHibernate dokumantasyonları ve/veya EF dokumantasyonları, forumları arasında bu nasıl yapılıyor, yaw bu neden olmuyor diye oldukca uzun sure debelendiler, buna bizzat tanık oldum. Kendim de zaman zaman her iki urunde de zorlandıgım noktalara denk geldim. Hatta gecenlerde gene burda senle konusmustuk Tuna, indeks vs yonetimi ile alakalı olarak.

Araclar bir takım isleri otomatize ettiginde dolayı benden daha iy sorgu yazabilir mi arka planda? Burada herseyden once normalizasyon adımları dogru tanımlanmıs, duzgun bir proje icin konusmak lazım. Yoksa o toollar napsınlar elbette. Ama gene de herseyin guzel oldugunu dusundugumuz zamanlarda arka planda hosumuza gitmeyen sorguların dondugune tanıklık ettik. Sırf NHibernate oraya gidiyor diye gereksiz bir kolona ayrı indeks dahi atmamız gerekti. EF te de aynı seyler var. Olay zaten marka model degil.

Peki DBMS imizi farklı bir marka-modele tasıma olasılıgımız var mı? Hayır zaten Sharepoint kullanıyoruz ana catı olarak, istesekte istemesekte Sql server 2x kullanıyoruz ve boyle devam edicez.

Ben bunları soyleyebilirim. Hani simdi ben bunları dusunmeden herseye evet diyemiyorum. İcinde bulundugum ekosistemi tradeoff lar mertebesinde kıyaslamak benim dogamda var. Aksi zaten kafayı kuma gommek olurdu.

Farklı alternatifler var olursa su anda aklıma gelmeyen gene buraya yazarım. Pamir de var bu projelerde, senin ekleyecegin birsey var mı ORM tercihi konusunda bize avantaj saglayan Pamir?
Sen de eklersen sevinirim.

09 Mart 2009 Pazartesi 18:31 tarihinde Tuna Toksoz <teh...@gmail.com> yazdı:

[Tuna Toksoz]

Index-query hint konusunda biraz daha sabir istiyorum. Artorius hazir oldugunda expression treeyle istedigin gibi oynayip indexleri ekleyebilirsin. Su anki haliyle de interceptor ile yanlis hatirlamiyorsam query ustunde oynama yapabilirsin.

NH oraya gidiyor dedigin seyi ogrenmek isterim.

Manevi abim Ayende bunlari yazmis, bunun ustune cok sey eklenir, benim soyleyeceklerim kisitli zira biliyorsun ki calismiyorum :)

• Partial Domain Models
• Persistent Specifications
• Googlize your domain model
• Integration with IoC containers
• Taking polymorphism up a notch - adaptive domain models
• Aspect Orientation
• Future Queries
• Scaling up and out
• Distributed Caching
• Shards
• Extending the functionality with listeners
• Off the side reporting
• Queries as Business Logic
• Cross Cutting Query Enhancement
• Filters
• Dealing with temporal domains

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/9 Tarik Kranda <tarik...@gmail.com>

una bizzat tanık oldum. Kendim de zaman zaman her iki urunde de zorlandıgım noktalara denk geldim. Hatta gecenlerde gene burda senle konusmustuk Tuna

[Tuna Toksoz]

Ayrica sorunun bi yerden sonra gelecegi yer su:

ASM mi C# mi ? - ya da diger bi deyisle portakal mi elma mi ?

NH ile yapabilecegin her seyi ADO.NET ile zaten yaparsin zira NH gokten gelen sorgu cevaplarini kullanmiyor.
Trade off budur. Getirisi budur, goturusu de odur. Query hintler geldikten sonra kullanacagina soz veriyorsan Artorius yapildiktan sonra query hintler ustune kod yazacagim soz.

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/9 Tuna Toksoz <teh...@gmail.com>

[Tarik Kranda]

:) Tuna biliyoruzki herhangi bir Search Engine de kısa bir arama ile bu sekilde tonlarca liste bulabiliriz, yuksek ihtimalle de Ayende ilk sıralarda gelecektir:)
Ben kendi projelerimiz de kullanan insanlar olarak nelere dikkat ediyoruz. Sonuc olarak demek istedigim herseyin bir getirisi ve goturusu vardır. Bunları goz onunde bulundurmak gerekir. Hayır ORM kullanılamaz demek te yanlıs bana gore, ki oyle olsaydım kullanmazdım, evet ORM konusu var ise tradeoff yapmaya gerek yoktur demek te yanlıs. Bu benim fikrim.

Ayende nin bahsettigi su baslıkların buyuk kısmı zaten bircok projede kullanılmıyor bir kısmı da zaten ORM in sagladıgı avantajlardan değil. Bir sonraki post unu da okudugum icin yazıyorum, evet sonuc olarak birisi digerinin uzerine geliyor.

09 Mart 2009 Pazartesi 18:55 tarihinde Tuna Toksoz <teh...@gmail.com> yazdı:

[Gökhan Altınören]

Alinti olmadigi icin Oguz'a mi bana mi ya da baskasina mi bu yazi anlamadim ama banaymis gibi bir seyler soyleyeyim dedim.

O kucuk post'u patronuna gostererek projeyi yonlendirecek elemanlar, ya da o post'u bulup tum bir ekibi baska bir teknolojiye yonlendirecek patronlar var bu dunyada. O yuzden yazarken dikkat etmek lazim. Ama asil konu o degil.

Google'da "NHibernate Code Generation" yazarak derya deniz bilgiye ulasiliyor. 3-4 sayfa giden 1-2 de alt linke dallanarak tum araclara ulasir neredeyse. NH mail grubunda sorabilir arayan, ya da forumunda. Bir ara Google Alerts'de "ActiveWriter" query'sine aboneydim, her hafta bir yerde birisi "Bu hbm.xml'leri nasil kolay uretirim, yok mu bir tool?" ya da "Var mi VS entegrasyonu" vs. derdi ve cevaplar arasinda illa ki ActiveWriter olurdu.

Ben kisisel olarak yukaridakinin erisilmesi cok kolay bir bilgi oldugunu dusunuyorum. O yuzden de bu konuda ~20 maddelik arastirma yapmis birinin, ozellikle de ilk iki siraya koydugu karsilastirma kriterlerini direkt etkileyecek bir araci es gecmesi bence onemli bir problem. Ayrica AW tek de degil, daha az kullanilan ve kendi basina ya da R# uzerinden VS entegrasyonu olan araclar da var.

Bundan yola cikarak, bu arkadas eger NH kullansaydi, NH'in OSS olmasindan dolayi zaten daginik duran bilgiye de zor ulasacakti hatta belki projesini bitiremeyecekti, o yuzden kendisi ve isvereni icin en dogru karari vermis (Ama eksik bilgiye bakarak vermis. Ama bilginin eksik olmasi da kendi eksikligi. O yuzden ona uygun arac, bilgiyi arastirma gerektirmeden kolay ulasabilecegi arac. Yani eksiklik eksikligini kapatiyor) diyorum ben.

Karsilastirma icin eldeki bilgiler tam olsa illa NH secilir demiyorum bu arada, o da yanlis anlasilmasin.

2009/3/9 Pamir Erdem <pamir...@gmail.com>

[Gökhan Altınören]

Zaman kazanci == Code.Gen bence bu isin en minimal getirisi. Asil getiri uzun vadede yonetilebilir uygulama olarak donuyor olmasi lazim, oyle degilse zaten ADO.NET mantiginda ORM kullanilmis olur.

Entity'leri projeye katmak metod parametreleri yerine insanlarin ortalikta nesneleri dolastirmasini sagliyor, ama mimari olarak ozel bir seyler yapilmadiktan sonra uzun vadede bir faydasi yok ki, karisan proje yine karisir. Iyi mimari olduktan sonra ADO.NET de isini gorur insanin.

Bu iyi ya da hizli sorgu beklentisine de katilmiyorum. Sizin firmada bir yazilimcinin bir ayinin toplam maliyeti ne kadar? Ortalama maas x 2 olarak hesaplayin. Projenin ilk senesinde yazilimcilardan birisi toplam 1-2 ay basitlik yerine optimizasyona kafa yorsa iki tane canavar gibi sunucu parasi cikar, normal olceklenebilir bir projede iki sunucunun cozemeyecegi bir performans problemi varsa eger orada zaten baska problemler vardir.

Normalizasyon derken DB normalizasyonsa eger, 3NF buyuk domain'lerde her zaman performansin dusmanidir onu da goz ardi etmemek lazim. Bence onemli olan dogru domain model'dir, DB ona bir sekilde uyar zaten. Ayrica domain model'deki her ifade DB'de oyle tertemiz de ifade edilemiyor, ama DB'ye bakan birisi schema'yi cikardiginda sikir sikir gozuksun diye domain'imi bukecek de degilim.

Genel olarak, ADO.NET'i ORM'e alternatif olarak gormek System.Net.WebClient'i WCF'e alternatif olarak gormekten farksiz bence.

2009/3/9 Tarik Kranda <tarik...@gmail.com>

[can ozturk]

Arkadaşlar kısa bir süredir sizin önerilerinizle nhibernate ve ef yi incelemekteyim . Şu an kullandığım yazılım geliştirme standardım şu şekilde;
Oracle veri tabanı üzerinde tüm sql cümlerini porcedurelere ve function lara koymaktayım. . net tarafında ise tüm veri tabanı işlemlerini
veri erişim katmanı içinde tanımlayıp , burdaki fonksiyonları iş katmanı aracığılıyla işleyip , sunum katmanında kullanıcıya göstermekteyim.
şu anda verileri datatable lara koymaktayım. Şu anki durumda yapmak istediğim tek sey datatable yerine verilere sınıflara koymak.
fakat kurumsal bir yazılımda bazen 4-5 farklı taabloyu birleştirip sorgulama yapmak gerekmekte. Bu yuzden tek sorgudan dönen değeri aynı anda birden fazla sınıfa veri atıp ardından tek griidde göstermek gerekiyor.tabi bu sadece kağıt üzerinde yapılabiliyor.
acaba nhibernate veya ef yi bu iş için kullanmak mümkünmü? yani ilişkisel tablolara karşı ilişkisel sınıflar.

09 Mart 2009 Pazartesi 22:28 tarihinde Gökhan Altınören <gok...@altinoren.com> yazdı:

[Tuna Toksoz]

relationlar mumkun, hql ile joinler mumkun
ef ile de mumkun

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/9 can ozturk <canalpe...@gmail.com>

[can ozturk]

genelde benim bulabildiğim örnekler de sql yerine nhibernate yardımı ile insert, update,select işlemleri yapılmış.
elinizde hiç dediğim tarzda bir örnek varmı

09 Mart 2009 Pazartesi 22:43 tarihinde Tuna Toksoz <teh...@gmail.com> yazdı:

[Tuna Toksoz]

http://www.hibernate.org/hib_docs/nhibernate/html/queryhql.html

[Pamir Erdem]

Bir firma anlaşma imzalarkan danışmanlık hizmeti alabilmesi üzerine çıkacak herhangi bir sorunda product'ın yetkilisini arayacak şekilde sözleşme imzalar. Bu yüzden NH le development yaparken yalnız başınasınız her hangi bir bug'da oturup ya mail atarsınız Fabio amcanın isterse yazar istemezse yazamaz ve Microsoft ile anlaşma yaparken herhangi bir bug da en az 2 gün içerisinde düzeltileceğini ve aksi takdirde para ödeyeceklerini bildirirler. Zamanında SQL Server da başımza böyle bir şey geldi. Bu tamamen sizin şirketinizin de politaksı olabilir. Batan proje her zaman batar ancak ne kadar düzgün şekilde battığı ve sorun çıktığında alacağınız destek önemlidir bugün community sözüyle işler yürümüyor ne yazıkki. Gönül işlerinin olduğu yerde büyük paraların döndüğü yerlere sokmak bir risktir bana göre. Bir de WebClient ve WCF karşılaştırılması yapılmış yazıları okuduktan sonra yorum yapmanızı rica ediyorum en azından bunu sakin kafayla okuyan biri zaten direk ne kastedildiğini anlayacaktır. Bu kadar basit cümleleri bile altında bakın ADO.NET le adam ORM'i karşılaştırıyor ne kadar cahil vah vah demeniz komiklik dikkatsizlik, ve üstün körü bir şeyler yazmaktır. Bugün burda bir şeyler yazıyorsam test edilmemiş, performance,güvenlik siyasi her hangi bir nedenden dolayı nedenini vererek izah ediyorum para transferi yoğun transaction dediğiniz kısımlar da ise lütfen yoğun size göre yoğun da olabilir
2000 transaction/sc altında sayıların küçük olduğunu bu tip durumlarda disk subsysteminizden database'in ram'e oranınai disk queue length'iniz batch compliation/sc kadar tonla bakmanız gereken yer olduğunu hatırlatmak isterim lütfen bu yüzden sayı veriniz. 

Saygılarımla
Pamir

2009/3/9 Tuna Toksoz <teh...@gmail.com>

[Murat Ozgur KAYMAKCI]

konunun tamamını okuyamadım fakat naçizane bir şey sormak istiyorum, tüm sql cümlelerini sp veya func'lara koymaktan kastınız business rule 'ları db 'de mi implemente etmek oluyor? yoksa atomic cümleleri mi sadece sp veya func lara koyuyorsunuz?

2009/3/9 can ozturk <canalpe...@gmail.com>

[Tarik Kranda]

Bu benim yazımla ilgili sanırım:) Cevabına tesekkurler Gokhan:) Ben burda sorumu iletirken tradeoff yapmadan gunun modasına uyarak uygulama gelistirmeye karsı oldugumu belirtermeye calıstım. Umarım bunun farkına varmanızı saglayabilmisimdir:). Oturup elmalarla armutları tartıp, saymıyorum elbette. Zaten ORM in alternatifi herhangi bir cozum de sunmadıgımı dikkatle incelerseniz goreceksinizdir:)Benim merak ettigim ORM kullanmak bir tradeoff mudur, oyle oldugunu dusunenler var ise, kendi projelerinde ne gibi kriterler kullanıyorlar. Sormak istedigim tamamıyle budur:))

Zaman ulkemizdeki en buyuk maliyet, ve geri donduremediginiz tek maliyet te bu. Ulkemizdeki bircok firmanın survival modda seyrettigini dusundugunuzde cogu zaman tradeoff larınızın icinde istesenizde istemesenizde zaman oldukca onemli bir yer kaplıyor.  Ancak burada implementation phase kapsamında kazandıgınız bir zaman ile maintenance phase de kazandıgınız zaman gene elma ve armut oluyor. Uzun vadade yonetilebilir cok fazla proje icinde calısmıs birisi olarak bunların icinde ORM olanlarda vardı, ORM kullanılmayanlarda. Aspect oriented programming yapan bir takımda da yer almadım hic bir zaman. Nitekim hali hazırda 2 NHibernate 1 EF projesi icinde dolanıp durmaktayım bir o tarafa bir bu tarafa.

Benim icin attıgım sorguların hızı ve mantıklı olması gercekten cok onemli. Bu konuda digerinde oldugu gibi size katılamıyacagım. TV de reklamı donen projelerde calısmak bircok kisinin rastladıgı olaylar degildir, fakat onemli bir case orneklemek acısından. Cok meraklı bir millet oldugumuzdan:) saniyeler icerisinde oldukca buyuk yukler altına giren projelerde gorev aldıgınızda milisaniyelere ve elinizdeki tum cacheleme alternatiflerine sonuna kadar ihtiyacınız oluyor. Eger size para veren musteriniz TV de bir reklama yer veriyorsa ve o reklamın sonucunda agırlasmıs ya da hizmet veremez bir servis ile karsılastıgınızda yiyeceginiz baskı sizi boyle dusunmeye itiyor. Zaten bu tarz projelerde kaybettiginiz reklam degeri 2-3 serverdan cok daha fazlasını alabilecek maliyette. Elbette her zaman proformance tunning calısması yaparak Query stats dususleri saglamak, Resource Utilization kazanımları saglamak mumkundur. Buna herkes sevinerek eyvallah der:) Burada toolları hakkını vererek kullanmakta oldukca onemli elbette.

Normalizasyon kapsamında bahsettigim post ta DB uzerinden konusmustum evet, fakat 3, 2 NF veya BCNF gibi bir ifade kullanmadım, soyledigim dogru ve yerinde normalizasyon. Gerekirse konsolidasyon , denormalizasyon. Cunku normalizasyon hatasının oldugu yerde istediginiz ORM aracını kullanın istediginiz performansı buyuk projelerde yakalamanız oldukca zorlasıyor. Kucukler oyle veya boyle islemeye devam edebilir, yasasın gelisen chip teknolojisi, artan IOPs thresholdları:) Nihayetinde insan beyninin yapamadıgı trikleri, isleri otomatize eden bir tooldan beklemek yanlıs olurdu. DB de saglayamadıgınız esnekligi domain e tasımanın tek yonetimi de zaten ORM degil.

Tum bunlarla beraber sozlerimin yanlıs anlasılmasını ve oturup bırakalım bu ORM islerini demedigimin altını 3-5 defa cizerek yineliyorum:)

Herkese iyi geceler.
Çalışanlara da kolay gelsin.

Tarık Kranda

09 Mart 2009 Pazartesi 22:28 tarihinde Gökhan Altınören <gok...@altinoren.com> yazdı:

Zaman kazanci == Code.Gen bence bu isin en minimal getirisi. Asil getiri uzun vadede yonetilebilir uygulama olarak donuyor olmasi lazim, oyle degilse zaten ADO.NET mantiginda ORM kullanilmis olur.

[Gökhan Altınören]

> Microsoft ile anlaşma yaparken herhangi bir bug da en az 2 gün içerisinde düzeltileceğini ve aksi takdirde para ödeyeceklerini bildirirler.

Oyle bir soylemissin ki duyan da MS Premier Support anlasmasi bedava sanacak, lisansi hic katmiyorum :) Incident basina saati 200$ ya da daha fazla (ve sanirim bulk aliyorsun, 400 saat falan), iki gunde bug fix eden product group da duymadim bunca senedir musterileriyim. Benim bildigim anca onceden cikmis bir hotfix vardir yayinlanmamis ona yonlendiriler iki gunde. 2 gunde SQL urun grubuna patch cikartmak buyuk is. Bravo diyorum.

MS'in yaptigi yanlis falan da demiyorum, profesyonel support istiyorsan parasiz olmuyor, olmasi da cok sacma olurdu, kaliteli yazilimin her zaman birine bir bedeli var. Ama ayni sekilde NH icin de parali support bulabilirsin, NH mailing list'e bir mail at, istemedigin kadar danismandan cevap gelecektir. Yukarida gecen paralari Fabio'ya ver, istedigin bolumu bastan yazar :) Yani biri icin ne varsa oteki icin de var, OSS da ekonomik bir model. Ayrica NH'de kendin de istedigin degisikligi yapabilirsin (firmanin lisans parasina yaptigi yatirima karsilik bunun da codebase'ini ogrenmeye ayirdigi zaman olarak dusun).

Ama NH'e takilarak asil baska bir riski bertaraf ediyorsun, discontinuity. 97'den beri MS platformu uzerinde para kazanan biri olarak yakin tarihten bir kac ornek:
- Object spaces. O kadar zaman harcadik, cikarmadi adamlar. Insani Go Live'i cikmamis pre-release MS teknolojisinden sogutan olay. Kumar gibi bir sey.
- Linq2SQL'in olumu. 2010'da L2SQL'de yenilik yok, EF'e abaniyorlar biliyorsundur. L2SQL musterilerine bunu onceden haber verdiler mi peki? 2011'de "Oslo tek yoldur, gecelim digerlerini" derlerse?
- Baska bir ornek, gariban ESP'ciler agliyor bu gunlerde (http://tech.slashdot.org/article.pl?sid=09/02/27/0413200).

Yani, parayi bastirdigin teknoloji iki sene sonra obsolate olabilir. Asil burada development yaparken yalniz basinasin malesef. Kucuk firmalari otturen, Turkiye olceginde buyuk bir firmanin IT muduru vardi, paket yazilim alsa source'unu da isterdi sanki kendine ozel yazilmis gibi (ve alirdi da, buyuk musteri). MS'den de source'lari istemisti deli gibi para dokuyorum size diye, cok gulmustu MS :)

> bugün community sözüyle işler yürümüyor ne yazıkki. Gönül işlerinin olduğu yerde büyük paraların döndüğü yerlere sokmak bir risktir bana göre.

Mozilla, SVN, Apache, PHP, Moodle, vs. Butun OSS community'lerde yuruyor da bunda neden yurumuyor? Gecmiste boyle bir olay mi oldu?. Eger support isteyip de alamadiysan nereye yazdin ne cevap aldin? nhusers grubuna uye ~1500 kisi var, her gun gozumun onunde bir suru soruya cevap veriliyor. Bundan daha saglikli nasil bir community olur merak ediyorum. eBay bunu bir risk olarak gormuyor mesela, bir cok yerde Hibernate kullaniyorlar. eBay bir ulke olsaydi dunyanin 6. buyuk ekonomisi olurdu bu arada, para isi dendigi icin soyledim.

> Bir de WebClient ve WCF karşılaştırılması yapılmış yazıları okuduktan sonra yorum yapmanızı rica ediyorum en azından bunu sakin kafayla okuyan biri zaten direk ne kastedildiğini anlayacaktır. Bu kadar basit cümleleri bile altında bakın ADO.NET le adam ORM'i karşılaştırıyor ne kadar cahil vah vah demeniz komiklik dikkatsizlik, ve üstün körü bir şeyler yazmaktır.

Cahillik, vizyon vs. bunlara takilip durma lutfen, benim kimseye boyle bir sey dedigim yok. "..gormekten farksiz bence." diye bitirmisim, bence boyle iste. Bence bu devirden sonra orta ve uzeri olcekli projede duz ADO.NET kullanma karari veren kisi cok cok ozel bir durum olmadigi (mesela cok garip raporlar. Cok transaction ozel durum degil bence, ORM'li ORM'siz her yerde var. Facebook olceginde baska seyler oluyor olabilir, onlarda isler bambaska yuruyor zaten) ve bunu justify etmedigi surece hata yapiyordur, preliminary optimizasyon yapiyordur vs. Bence hatalidir, WebClient vs. WCF orneginden farki yoktur, bu ornek te bence gayet guzeldir.

> ...
Gecen SQL danismanimizla bir musterinin uygulama altyapisindaki tikanikligi inceliyorduk, uretim sirasinda bir kac fabrikada binlerce sensorden alinan real time verinin yine real time degerlendirilip bir yandan da fabrikalar arasi replicate olmasi vs. Klasik mimarilerde olceklenebilirligin yuk arttikca geometrik olarak nasil dustugunu incelemek acisindan cok eglenceliydi (oradaki IT ekibi boyle dusunmuyordur tabi :). Emin ol high load / high throughoutput konusunda yeterli ornek inceledim ve cozum gelistirdim, salliyor degilim. Mesela bu musteride Replicating masters / Multiple read slaves onerdik. Writelar master'lara, read'ler slave'lerden. Replication lag'leri azaltmak icin sunucu konfigurasyonu ve network altyapisi onerileri de oldu. Shard'lara kadar yolu var ama simdilik gerek yok.

Sonuc olarak, benim canimi sikan sey Java'cilar vs. icin deli enterprise ortamlarda yillardir tikir tikir calisan seylerin MS camiasinda sanki dandik teknolojiymis gibi lansmani. 90'larin sonunda Java tarafinda EJB yerden yere vurulurken MS'in karsilik gelen enterprise teknolojisi VB6 uzeinde ADO recordset'leri onune COM'u koymakti :) EJB'nin yerine neredeyse defacto olan teknolojiyi bu kadar da hafife almamak lazim.

Yazdiklarim basimdan gecenler sonucu vardigim noktadir, komiklikle, ustunkoru bir seyler karalamakla isim olmaz.

2009/3/9 Pamir Erdem <pamir...@gmail.com>

[can ozturk]

.net tarafında kodların arasında sql cümlelerini yazmıyoruz(istisnalar hariç). sql cümlelerin hepsi oracle procedure ve functionlarının içinde. tabi onlarda ilgili packagelarının içinde.Bunlara karşılık veri erişim katmanında bu procedurler çağrılıp işlem yapılıyor.
bu şekilde yapılmasının sebebi genel itibariyle oracle ın extra performans sağlayıcı özelliklerinden faydalanabilmek.

10 Mart 2009 Salı 00:00 tarihinde Murat Ozgur KAYMAKCI <murat...@gmail.com> yazdı:

[Ömer KUL]

+1.

Benim de business katmanım .Net tarafında olmasına rağmen, Repository katmanı ile Veritabanı arasındaki bütün iletişimim SP ler ile oluyor. bu durum eleştiriliyor olsa da faydası yüzünden ben kesinlikle tercih ediyorum. 

Oracle için(Sql Server için de benzer bir durum var) bir statement 3 fazdan geçerek işletilir. Parse,Execute ve Fetch. Parse aşamasında bütün syntax hataları bulunur, haklar kontrol edilir ve obje bağımlılıkları çözülerek Execution planı çıkarılır. SP ler bu hali ile saklanır ve her çağrıldığında direk Execution fazından başlar. ORM toolları ise ilk fazdan başlar. bu performans artısı için bence SP ile iletişim kurulması oldukça mantıklı.  burada önemli olan SP lere business yüklememek.

Ömer KUL

---

From: can ozturk <canalpe...@gmail.com>
To: altdotne...@googlegroups.com
Sent: Tuesday, March 10, 2009 10:11:38 AM
Subject: Re: NHibernate & Entity Framework (ado.net 3.5 ile) Karşılaştırması

[onur eker]

Merhabalar,

Oğuzun bahsettiği projeyi geliştiren takımın lideriyim..

Sanırım öncelikli olarak projeyi çok kısa bir şekilde anlatmak gerekir.
Bu proje, şimdi adını veremeyeceğim ve dünya çapında en büyük bankalardan biri olan bir bankada hazine departmanı tarafından pozisyon takip etmek için kullanılmakta. Projenin içerisinden; o gün bankaya gelen ve giden tüm eft ve havale işlemleri, hem gerçekleşen hemde gerçekleşmesi beklenen transactionlar olarak takip edilmekte. Aktif olarak iki senedir production ortamında sorunsuz bir şekilde çalışıyor.

Projedeki yaklaşık olarak veri akış şeması ise şöyle:
Gerçekleşen incoming eft işlemleri : 20000 transaction
Gerçekleşen outgoing eft işlemleri : 20000 transaction
Beklenen incoming eft işlemleri : 20000 transaction
Beklenen outgoing eft işlemleri : 20000 transaction

Oğuzun da bahsettiği gibi transaction'ların hepsi yalın halde ve farklı thread'ler aracılığı ile çekiliyor.

Bunun dışında bu transactionların joinlendiği statik tabloların kayıt sayırları ise aşağıdaki gibi.
Bankalar: Yaklaşık olarak 19000 transaction
Müşteriler: Yaklaşık olarak 9500 transaction
Hesaplar: Yaklaşık olarak 12000 transaction
Currency: Yaklaşık olarak 40 transaction

Bu arada şunuda unutmamak gerekir ki bazı statik tablolar ile (örneğin banka ve müşterihesapları) iki kere join edilmesi gereken durumlarda bulunuyor..

Nihayi olarak şunu söyleyebilirim ki; projenin bir ekranında yaklaşık olarak 40000 transaction'ın çekilmesi, joinlenmesi ve ekrana basılması 2 saniyenin altında sürmekte.. Yani saniyede 2000 transaction değil 20000 transaction çekilmekte ve ekrana basılmakta..

Bu durumda nhibernate için bence performans üzerine konuşmak rakamlardan da anlaşılacağı üzere oldukça gereksiz kalıyor.
Oğuzun da belirttiği gibi nhibernate'i kullanma şekli en kritik olan karar.

NOT:: Bu arada "Ömer KUL kardeşime" biraz taklıarak birazda sitem ederek diyorum ki...
"O kadar öğrettiklerimizden ve konuştuklarımızdan sonra hala sp'ler ile veriçekmek için +1 ;))))...
Bunları Cuma konuşuruz kardeşim ;))"

Saygılar

2009/3/9 Pamir Erdem <pamir...@gmail.com>

[Tuna Toksoz]

Eski versiyonlarda bu olabilir fakat sql server ve sanırım artık dinamik sorguarın da execution planlarını saklıyor.

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/10 Ömer KUL <kul_...@yahoo.com>

[Berke Sokhan]

Oracle da saklıyor Ömer, eğitimleri hatırla :))

2009/3/10 Tuna Toksoz <teh...@gmail.com>

--
Berke SOKHAN

[Gökhan Altınören]

SQL 2000 itibariyle sakliyor.

2009/3/10 Tuna Toksoz <teh...@gmail.com>

[can ozturk]

galiba oracle ve sql server bu konuda biraz farklı çalışıyolar. Oracle sql ler parse edip bi dahaki kullanımlar için shared memory sinde
saklıyor.Aynı sql cümlesi yada bind değişken olarak kodlanan farklı parametreli  sql cümleleri bu özellikten faydalanıyor.
anladığım kadarı ile sql server da ise bu aşamadan sonraki execution plan oluşturma kısmı saklanıp her seferinde aynı execution plan ile çalışması sağlanıyor. Sql server konusunda yanılıyoda olabilirim.

Fakat 3-4 tablonun birleştirildiği, 7- 8 farklı parametre ye göre arama yapıldığı bi de bunların sayfalanarak getirildiği bir sql cümlesinin
bir kere parse edilip defalarca kullanılabilmesi ufak da olsa kazanç sağlıyor.

2009/3/10 Gökhan Altınören <gok...@altinoren.com>

[Ömer KUL]

Herkese tekrardan selamlar,

biraz cevap hakkı doğdu sanırsam :)

Evet Oracle saklıyor ama Saklı yordamları sakladığı şekliyle aynı değil. Saklı yordamlar için ayrı bir yapısı var. Dinamik gelen sql leri cache-leme şeklinde saklıyor. sık sık çalıştırılan dinamik sql ler ancak memoriden getirilebilir. Sql server hakkında bu kadar ayrıntılı bilgim yok malesef.

 

Onur kardeşime :)

Ben aslında ORM tool-ları kullanılmasın demiyorum. Çalıştığım şirketimde kullanamama rağmen kendi kendime öğrenmek için kitaplar bitiriyorum :). Orada +1 dememin nedeni benim durumumda da SP kullanılması gerektiğindendi. Genel olarak ORM kullanımı kesinlikle doğru bir yaklaşım. Benim projemi biliyorsun zaten kardeşim, saniyede onlarca kez veritabanına gidip, 10 binlerce kayıt getiriyor. ve bu kayıtları datatable da tutup NQuery ile sorgulamam gerekiyor.

 

Herkese sevgiler,

kolay gelsin...

---

From: Berke Sokhan <berke...@gmail.com>
To: altdotne...@googlegroups.com
Sent: Tuesday, March 10, 2009 2:14:47 PM

Subject: Re: NHibernate & Entity Framework (ado.net 3.5 ile) Karşılaştırmas

[onur eker]

Senin proje özelinde doğru bir çözüm tabii kardeşim...
Ama dediğin gibi senin proje özelinde, yani genel anlamda doğru bir yaklaşım değil..
Ki sende bundan dolayı nhibermate referans dökümanını hatim ediyosun sanırım ;))))

2009/3/10 Ömer KUL <kul_...@yahoo.com>

[Berke Sokhan]

Ömer'le aynı projede başka ekiplerdeyiz, bence proje özelinde de hiç doğru değil  :PPP

(şaka şaka, ortalık çok gerilmiş :)))

2009/3/10 onur eker <onur...@gmail.com>

--
Berke SOKHAN

[Ömer KUL]

:) gerilme yok canım... hatta güzel oldu.

bu arada Oracle 10g ile birlikte SP ile Sql çalıştırma arasındaki farklar oldukça azalmış. (Eskiden ilk madde direk performans olurdu.) Özel durumlara göre Sql-lerin SP den daha hızlı çalıştığı da olabiliyormuş. Yani ORM araçları artık -1 den başlamıyor. aşağıdaki avantajları hala var ama ORM nin avantajlarını da düşününce ihtiyaca göre değişebilse de ORM daha doğru olacaktır.

 

benim durumumda hala SP gerekiyor. SP deki her sorgum 400-500 satır civarında. her çağrımda bu kadar veriyi veritabanına geçirmektense 4 parametre geçirerek network bandwith inden kazanmam gerekiyor.

 

The advantages of using stored procedures are:

1) Network Bandwidth: Assume that the application server(s) and the database server(s) are separate servers. Since the source code is actually stored on the database server, the application only needs to send the name and the parameters for executing it and this in turn reduces the amount of data that is sent to the server. When you use embedded SQL or dynamically generated SQL through an ORM, then the full source of commands must be transmitted and in a scenario where there is a lot of concurrent activity going on and the load on the system requires a lot of users, this can very soon become a performance bottleneck. This can be mitigate in part by a judicious usage of views as well.

2) Abstraction Layer: It helps in separating the business logic from data manipulation logic. Since the interface to the application remains the same, changes done internally to the stored procedures/packages do not effect the application and in turn leads to easy deployment of changes.

3) It offers simplified batching of the commands. Since stored procedures/packages are meant to do a “Unit of Work”, this procedural logic can be simple to maintain and offers additional advantages like making use of the rich feature functionality that the database engines provide. SQL is a SET based language and using SET based procedural logic is the easiest and most performant way of dealing with the data. With every new release of Oracle, SQL Server or DB2 LUW, new features are being introduced in PL/SQL, T-SQL and/or SQL/PL which makes handling of different types of requirements very easy in the DB layer code.

4) Increased data security and integrity: One can secure the tables for direct access and only grant privileges on the stored procedures/packages.

5) By using bind variables (parameterized queries), SQL injection issues are mitigated as well.

6) Code Instrumentation and tracing logic can be built in very easily using the stored procedures. This is one thing that we implemented for one of our clients recently. We created a table which had a list of the DB code that was being used in the schema and this table had a trace_flag column in it which could have 4 different values:

---

From: Berke Sokhan <berke...@gmail.com>
To: altdotne...@googlegroups.com

Sent: Tuesday, March 10, 2009 4:38:54 PM

[Gökhan Altınören]

1. Maddeye super katiliyorum, alternatifi de yok. Ozellikle kompleks raporlama ya da birbirine bagli insert'ler gibi durumlarda performans direkt fark ediyor.

Diger maddeler bence kod icinde olmasi gereken maddeler.

2009/3/10 Ömer KUL <kul_...@yahoo.com>

[Berke Sokhan]

Ömer, alıntı yaptığın yeri belirtmeyi unutmuşsun...

2009/3/10 Gökhan Altınören <gok...@altinoren.com>

--
Berke SOKHAN

[onur eker]

;))) geçektende ne gerilmesi ;))

2009/3/10 Ömer KUL <kul_...@yahoo.com>

[Sidar Ok]

Yaw bi haftasonu tatil yaptik en eglenceli bolumu kacirmi$iz :)

Ben ingilizce grupta tarti$masini yaptim, kesmedi turkcesini de yappim bunun dedim ondan kurduk bu grubu :D :D $imdi de kacirdik bak, olmadi ki.

Mesajlari okudum, NH vs EF konulu 5 post felan var. ORM vs SP, Code Generation vs Hand crafted Modeling, Microsoft vs Open Source, To be vs Not to be diye bir cok konuya deginilmi$ saolsun :)

$unu soylemek istiyorum sadece, madem serbest forum haline gelmi$ burasi, bi ce$ni de ben katayim :) MS in L2S i EF icin birakmasi o corporate support denen $eyin ne kadar yalan oldugunun en buyuk gostergelerinden biridir aslinda. Ben 4 milyar dolarlik ciro donen2 sistemi L2S uzerine kurmu$um, sonra gel de ki bundan sonra bunu kullanmayin EF kullanin...e o zaman ne anladim bu cinsel cekimden :)

Derdimi bir $iirle anlatmak istiyorum izin verirseniz, gecenin bu saatinde:

ORM li $iir

L2S, seni nasil sevmi$tim oysa ki  ( http://www.sidarok.com/web/blog/content/category/linq )
Ama artik EF kullanmam gerek.
Belki POCO icin 2.0 i beklemem gerek,
Belki Canonical Model bi antipattern demek,
Bir suru iyi prensibi
EF icin ihlal ediyorum bebek...
Ihlal ediyorum!
LoD, Interface Seggragation vs i
Ve sevmek zorundayim, o iki mapping layer i
$imdi hayatimiz, bir XML cehennemi olsa da
Bir zehir olsa da ayni anda 2 ki$inin o designer da cali$masi,
Acik havada designer xml lerini merge etmemeyi oneriyordu radyolar...
Ve ben $imdi,
EntityObject kar$isinda yitirirken sabrimi,
L2S ile yazdigim, domain driven application lari du$unuyorum
Gozlerim kapali...

2009/3/10 onur eker <onur...@gmail.com>

--
Sidar Ok
http://www.sidarok.com

[Ömer KUL]

Alıntı yaptığım yer google Cache ile geliyor. gerçek sayfasına ulaşamadım. o nedenle de renkli renkli koymak istemedim :P

---

From: Berke Sokhan <berke...@gmail.com>
To: altdotne...@googlegroups.com

Sent: Tuesday, March 10, 2009 5:58:26 PM

[Tuna Toksoz]

Aman Allahim, dunyada L2S ve EF e siir yazan ilk kisi sen olabilirsin.

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/11 Sidar Ok <sid...@gmail.com>

[Tuna Toksoz]

MVP olmusun sen.
Most Valuable Poet (sidarin kendi esprisi). Bu unvani zipleyip ceyizine koyar artik

Tuna Toksöz
http://tunatoksoz.com
http://turkiyealt.net
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/3/11 Tuna Toksoz <teh...@gmail.com>

[Berke Sokhan]

eheh güzelmiş bu şiir, dişe de dokunuyor...

(bi süre gmailime ulaşmadım da: Checkpoint SecuRemote)

2009/3/11 Tuna Toksoz <teh...@gmail.com>

--
Berke SOKHAN

[Doga Oztuzun]

Merhaba,

EF'yi .NET 4.0'da inceleyenler yeni versiyon ile eklemek istedikleri birsey var mi ?

2009/3/10 onur eker <onur...@gmail.com>

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

--
http://www.DogaOztuzun.com/