Yorumları: 820
Konuları: 135
Kayıt Tarihi: 07-12-2017
Aktif Kullandığınız Delphi Sürümü:
Rep Puanı: 3.030
Uzman
Selamlar Arkadaşlar
2 gündür bahsi geçen ORM denen şeyin Avantaj ve Dezavantaj'ları nelerdir diye bazı yazıları takip etmeye çalışıyorum.
Program geliştirirken avantaj olan bir şey ileride program içerisine gömülen belli bir yapı nedeni ile dezavantaja dönüşür mü?
Yada ORM aracı yazılımcı için zaman yada kodlama kolaylığı getirirken Kurum ve Projeler in yaşam döngüsünde bir sorun teşkil eder mi?
Program yazım aşamasında artı olan bir şey çalışma sırasında performans ve izlenebilirlik konusunda sorun oluşturur mu ?
Bu konudaki ORM araçlarının +/- yönleri hakkında görüşleriniz nelerdir.
Teşekkürler
Bu dünyada kendine sakladığın bilgi ahirette işine yaramaz.
Yorumları: 176
Konuları: 0
Kayıt Tarihi: 01-09-2016
Aktif Kullandığınız Delphi Sürümü:
Rep Puanı: 552
Acemi
Naçizane fikrimi söylemem gerekirse,
.net tarafındaki olay aslında klasik Ado netten kurutulup daha kolay bir yapıya geçmeleridir.
Classlar olarak oluşturduğunuz Entitesleri doğru mimaride doğru şekillerle bağladığınız da
bütün bir databaseye yeni oluşturacağınız claas ile insert update delete yada select gibi işlemleri hiç yorulmadan yapabildiğiniz bir ortama dönüşmekte.
Bunun yanında .net tarafında Code First denilen yapıda kullanıcıya ciddi emekler vermekte ama bu emeklerin clasic adonet tarafında daha da zorlu bir süreci geçiyor.
Mimaride ciddi değişiklikler yapılacaksa Örneğin
MSSQL serverden Oracleye geçeceksek yada daha büyük bir değişim hibernate gibi bir platforma geçeceksen
.net tarafında context dedikleri yapıda tek satırlık değişimle bütün projeyi farklı bir yapıya çevirmek mümkün,
mümkün olduğu gibi normalde yüzlerce binlerce yazdığınız satırların %90 'ı da gitmekte.
Örneğin MSSQL den çektiğiniz bir SQL Query den dönen dereği hiçbiryere yüklemeden liste şeklinde alıp aldığınız listenin içinde sorgulama yapma gibi bir durum var
Ben buraya fazla hakim olmamakla birlikte gördüklerimi sadece dile getiriyorum.
Database tarafında oluşturduğunuz Entitiesler sizin tablolarınız olduğu için bütün hepsi ile program ara yüzünde bağlantı kurmak istersen kurduğun gibi kurmak istemezsen de kurulmasın diye belirtebiliyorsun.
TMS Aurelius'in videolarını izlediğimde yaptıkları da zaten bu çatı altında bir geliştirme olmuş
Saygılarımla
Yorumları: 297
Konuları: 34
Kayıt Tarihi: 28-03-2017
Rep Puanı: 2.072
Programcı
Delphi'de ciddi anlamda herhangi bir ORM aracı kullanan kimse yok mudur? Öyle bir arkadaşımız varsa ve tecrübelerini paylaşırsa bizler de faydalanmış oluruz.
Yorumları: 953
Konuları: 124
Kayıt Tarihi: 06-07-2017
Aktif Kullandığınız Delphi Sürümü:
Rep Puanı: 6.375
Üstad
Merhaba,
.NET platformunda ürettiğimiz uygulamalarda Entity Framework ve kendi kurguladığımız, dünya çapında kabul görmüş n-tier (çok katmanlı) yapılarda ORM tercih ediyoruz. En büyük avantajı bir projenin altyapısı doğru sistemati ile kurduğunuz zaman sizi hata yapmaktan alıkoyuyor olması. Büyük projelerde özellikle takım çalışmalarında herkesin her şeyi ezbere bilmesi gibi bir şey söz konusu değil. Bu yüzden bir stil oturttuğunuz zaman ORM yapıları veritabanı tasarımınızdaki standartları koruyup, Entity (varlık) üzerinden çoğul-tekil ilişkileri aşırı konforlu bir şekilde kullanmanızı kolaylaştırıyor.
Ben gerek Object Pascal, gerekse C# kodlamalarım için kendi sistemlerimi ve mimari yapımı oluşturuyorum. Veri erişim katmanlarından IoC konteynır kullanımına, Ninject, Fluent Validation, PostSharper, Castle gibi kütüphanelere ve sistemleri de implement ediyorum. Tasarım desenlerini hakkıyla kullandığınız zaman işinizi daha pratik ve daha sistematik yapacağınız her türlü kütüphane faydalıdır. Ancak burada projenin canlı kalması, desteğinin sürdürülmesi, versiyon geçişleri gibi kritik meseleler var. O yüzden yaygın kitleler tarafından kabul görmüş kütüphane ve bileşenlere başvurmakta fayda var.
Şimdi gelelim asıl istenilen cevaba;
+/- Notları
+ Pozitif yanları
1) Database-First (ilk önce veritabanı tasarımı) yaklaşımı ile geliştirilen projelerde ORM framework sizin yerinize tüm ilişkisel veritabanınızın CRUD işlemlerini ve modellemelerini çıkartır.
2) Veritabanında yaptığınız değişiklikleri override ederek tek bir hamle yapmadan düzenler, ilaveleri ekler. Sizin yapacağınız tek şey View/Presentation katmanı ile iş katmanlarınızı bağlamak.
3) Eğer veritabanının tasarımını doğru yaptıysanız, ekibin en az tecrübelisini rahatlıkla projeye sokabilirsiniz. Ona tercih imkanı veya hata yapma imkanı bırakmaz.
4) Erişim katmanı (Access) kodlarına dokunmadığınız için oluşan context veritabanından bağımsız olarak bir veritabanı kalıbı taşır. Böylece veritabanı sürücüsü değiştirerek anında projeyi X veritabanı sisteminden Y veritabanı sistemine taşıyabilirsiniz. (Proje kodlarında SQL Server ile koşan projeyi Oracle'a taşımak 5 dk sürmüştü.)
- Negatif yanları
1) Sizi kesinlikle tembelleştiriyor ve bağımlı hale getiriyor. Ama buna pozitif yandan bakarsak, camia içindeki jargonuyla kod ameleliği yapmanıza gerek kalmıyor olması.
2) Kullandığınız sistemlerdeki versiyonların birbiriyle doğru çalışması için bir versiyon eşlemesi yapmanız gerekiyor. Ekosistemin içinde hızlı gelişen parçalara ayak uyduramayan parçalar sizi sıkıntıya sokabiliyor.
3) Hatalı veya çok revize gören veritabanı yapılarında kodlanmış projenizde geri dönüşler biraz daha vakit alıcı oluyor.
4) Bu tarz sistemler kendi çalışma mekanizmalarını getirip sizin projenize eklediği için klasik ado.net bağlantısından aldığınız hızı alamayacağınız projeler olabilir. Bunun tek sebebi ORM değil, çevre birimleri, donanım kalitesi ve evsafı, internet altyapısı vs. ancak ORM'nin transaction hızı çok etkili. Özellikle asenkron işlemlerin adedi büyüdüğü zaman.
5) Yapısal değişikliğe gidildiğinde veya başka bir teknolojiyi projeye dahil ettiğinizde doku uyuşmazlığı oluşturabilir. VCL projeyi FMX'e çevirdiğinizde FMX desteği olmaması gibi.
