Entity Nedir?

Bu yazı 13 Mart 2019 tarihinde Medium/@dynamics365 altında yayınlanmıştır. 01 Mayıs 2020 tarihinde emregulcan.com altında taşınmıştır.

İçerikler, yazının oluşturulduğu tarih için geçerli olup, Microsoft Dynamics 365 CE, Power Platform ve Azure hizmetlerinin sürekli iyileştirme ve güncelleme döngüsünden dolayı paylaşılan bilgilerde değişiklikler meydana gelmiş olabilir.

Merhaba,

Bu yazımızda Dynamics 365 CE (CRM) SDK ‘da genel olarak Entity ve Early-bound ile Late-bound kavramlarını inceleyeceğiz.

Entity

Entity, Dynamics 365 CE (CRM) veritabanında herhangi bir tabloda bulunan kayıt bilgisidir. Dynamics 365 CE (CRM) SDK ‘da Early-Bound ve Late-Bound olmak üzere 2 farklı şekilde kullanılmaktadır.

Early-bound Entity

Early-bound Entity ‘ler basit anlamda Dynamics 365 CE (CRM) ‘de bulunan Entity (Varlık) ‘lerin .NET Class olarak kullanılabilir halidir.

Early-bound Entity oluşturmak için Microsoft tarafında resmi olarak sunulan CrmSvcUtil isimli command-line uygulamayı ya da XrmToolBox ‘da bulunan Early Bound Generator isimli plugin ‘i kullanmamız gerekmekte. CrmSvcUtil ve XrmToolBox ‘ın kullanımı bu yazının konusu olmadığı için detaylara girmiyorum, daha sonra farklı yazılarda bu konuları inceleyeceğiz.

Early-bound Entity dosyamızın içeriği herhangi bir .NET Class ‘dan farklı değildir.

Aşağıda görüldüğü gibi Microsoft.Xrm.Sdk.Entity ‘den türetilmiş Account isminde bir Partial Class bulunmakta, bu Dynamics 365 CE (CRM) ‘de bulunan Account varlığının .NET (C#) Class halidir ve database ‘de bulunan tüm alanları Property olarak içermektedir.

Oluşturulan Early-bound Entity dosyamızı projelerimizde aşağıdaki gibi kullanabiliriz.

Early-bound Entity
Early-bound Entity
Early-bound Entity ‘nin projede kullanılması
Early-bound Entity ‘nin projede kullanılması

Early-bound Entity ‘ler Partial Class olarak oluşturulduğu için, projemizde aynı isimle farklı bir Partial Class oluşturup, bu class ‘a yeni property ‘ler ekleyebilir ve business metotlarımızı bu yeni class içinde yazabiliriz. Burada dikkat etmeniz gereken en önemli nokta, Early-bound class ‘ın ve bizim oluşturduğumuz Partial Class ‘ın aynı Namespace altında olmasıdır.

Eğer Early-bound Entity oluştururken /namespace parametresini kullanmayıp direkt olarak oluşturduysanız, projenize eklediğiniz Partial Class ‘da namespace ... bölümünü kaldırmanız gerekmektedir.

Partial Class — Account
Partial Class — Account

Avantajları;

  • Class olduğu için projemizin derlenmesi aşamasında (compile) tür ve veri güvenliği sağlamaktadır (Strongly-typed)
  • Intellisense tarafından tanındığı için development aşamasında hız kazandırır
  • Kodun kolay anlaşılmasını sağlar

Dezavantajları;

  • Eğer Entity bazında filtreleme yapmadan tüm entity ‘leri Early-bound olarak oluşturuyorsak dosya boyutu çok yüksek olacaktır (yaklaşık 30 MB civarında), bu da projemizin boyutunu arttıracaktır
  • Yeni bir Entity oluşturulduğunda ya da mevcut Entity üzerinde bir değişiklik yapıldığında Early-bound dosyamızı yeniden oluşturmalı ve projemize dahil etmeliyiz. Bu nedenle aktif olarak Customization (Özelleştirme) işlemleri devam eden projelerde Early-bound Entity yapısı kullanmak çok doğru olmayabilir
  • Plug-in ve Workflow Assembly içinde kullanmak istediğimizde IL-Merge vb. bir araç kullanarak farklı DLL dosyalarını tek bir DLL olarak birleştirmemiz gerekebilir

Late-bound Entity

Entity (Microsoft.Xrm.Sdk.Entity) direkt olarak Late-bound Entity ‘nin kendisidir desek yanlış olmaz.

Late-bound Entity kullanarak işlem yapmak için herhangi bir ek iş yapmamıza gerek yoktur, projemizde Microsoft.CrmSdk.CoreAssemblies ekli ise (Microsoft.Crm.Sdk.Proxy.dll ve Microsoft.Xrm.Sdk.dll) direkt olarak Entity class ‘ını kullanabiliriz.

Aşağıdaki örneklerde görüldüğü üzere Entity olarak bir nesne oluşturduk ve Constructor üzerinden account değerini gönderdik, bu sayede Dynamics 365 CE (CRM) ‘de hangi Entity (Varlık) üzerinde çalışacağımızı belirttik.

Late-bound Account Entity — Örnek 1
Late-bound Account Entity — Örnek 1
Late-bound Account Entity — Örnek 2
Late-bound Account Entity — Örnek 2

Late-bound Entity, Early-bound Entity ‘de olduğu gibi Property ‘lere direk erişim sağlamaz yani Strongly-typed değildir. Bunun yerine KeyValuePair<string,object> yapısında data saklayan Attributes isimli bir property ‘e sahiptir.

Early-bound Entity ‘de Account.Name olarak kullandığımız yapının Late-bound Entity ‘de karşılığı account["name"] ‘dir.

KeyValuePair<string,object> yapısında Key (string) ilgili alanın adını (database tablosunda kolon adı), Value (object) ise bu alana gönderilecek değeri belirtmektedir. object olmasının sebebi ise farklı data türleri ile (EntityReference , OptionSetValue , string , int, DateTime vb.) işlem yapmamıza imkan sağlamaktır.

Özel data türleri (EntityReference , OptionSetValue) için sonraki yazılarda detaylı bilgilendirme yapacağım.

Avantajları;

  • Projemizde Microsoft.CrmSdk.CoreAssemblies ekli olduğu sürece, CrmSvcUtil vb. gibi başka bir yapıya ihtiyaç duymadan direk olarak kullanılabilir
  • Herhangi bir bağımlılığı olmadığı için Customization (Özelleştirme) işlemleri aktif olarak devam eden ya da gelişmeye açık olan projelerde rahatlıkla kullanılabilir. Yeni bir Entity (Varlık) oluşturulduğunda ya da mevcut Entity üzerinde bir değişiklik yapıldığında sadece ilgili kod bloklarında entity["attributename"]=value; şeklinde eklenti yapılması yeterli olacaktır
  • Plug-in ve Workflow Assembly içinde direkt olarak kullanılabilir ve IL-Merge vb. araçlar ile DLL tekilleştirme işlemi yapmaya gerek yoktur
  • Early-bound Entity ‘de olduğu gibi herhangi bir dosyaya bağımlılık olmadığı için proje boyutumuza olumsuz bir etkisi yoktur

Dezavantajları;

  • Strongly-typed bir yapı sunmadığı için Entity oluştururken isimlendirme ve data türü hatalarına açıktır. Yazılımcının Dynamics 365 CE (CRM) tarafında oluşturulan her alan için data türü bilgisine hakim olması gerekmektedir
  • Olası hatalar compile aşamasında değil, direkt olarak çalışma aşamasında (runtime) belli olur. Bu nedenle uygulamaların iyi test edilmesi gereklidir
  • Intellisense tarafında tanınmaz

Performans Karşılaştırması

Performans olarak Early-bound ya da Late-bound arasında çok büyük farklar olmamakla birlikte, Dynamics 365 CE (CRM) SDK ‘da Best Practices konusunda if your custom code works with thousands of entity records, use Entity class, results in slightly better performance than the Early-bound entity types açıklaması bulunmaktadır. İşin özü, binlerce kayıt üzerinde çalışıyorsanız Late-bound kullanmanız önerilmektedir.
Internette performans konusu ile ilgili olarak araştırma yaptığınızda benzer şekilde hazırlanmış farklı blog yazılarına erişebilirsiniz. Bu yazılardan birinden aldığım performans değerlendirmeleri aşağıdaki gibidir.

Early-bound ve Late-bound Performans Karşılaştırması / Düşük hacimli işlem
Early-bound ve Late-bound Performans Karşılaştırması / Düşük hacimli işlem
Early-bound ve Late-bound Performans Karşılaştırması / Yüksek hacimli işlem
Early-bound ve Late-bound Performans Karşılaştırması / Yüksek hacimli işlem

Umarım faydalı bir yazı olmuştur.


Dynamics 365 CE (CRM) SDK konusunda ilgili tüm yazılara tek nokta üzerinden ulaşmak isterseniz http://www.emregulcan.com/dynamics365-sdk adresine bakabilirsiniz.

You may also like...

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Bu site, istenmeyenleri azaltmak için Akismet kullanıyor. Yorum verilerinizin nasıl işlendiği hakkında daha fazla bilgi edinin.