Sınıf isimlerinin açıklayıcı olması, yalın olmasından önemli, ama 10 kelime de çok fazla olur, ona göre bazı kelimelerin kısaltmasıyla isim standardı oluşturulabilir. Projenin daha anlaşılır olmasını sağlıyor. Yapıcı metodu genelde bir sınıfın referansında tutulacak default değerleri belirlemekte kullanıyoruz. Burada RuleFor'un yapıcı metotta olmasının sebebi kullanıcının girdiği değerle bu kuralı karşılaştırması olabilir.
FluentValidation: RuleFor()'un constructor içinde belirtilir çünkü bu sınıfın ilk oluşturulduğu anda doğrulama kurallarının tanımlanmasını sağlar. Yani bir sınıf örneği oluşturulduğunda doğrulama kurallarının hemen tanımlanmasına olanak sağlar ve bu nedenle bu kuralların sınıfın yaşam döngüsü boyunca geçerli olması sağlanır.
Burada Constructor(Yapıcı) metodu: AppUserRegisterDto sınıfına erişebilmek için bir nesne oluşturup ve bu oluşturulan nesneye otomatik olarak yapılmasını istediğimiz işlemleri yazıyoruz
Constructorı kek yaparken kullandığımız bir kap gibi düşünelim. Tıpkı kek hamurunu karıştırmaya başlamadan önce kabartma tozunu eklediğimiz gibi nesneyi oluşturmaya başlarken de constructor içinde doğrulama kurallarını eklememiz gerekiyor. Çünkü constructor bir nesnenin oluşturulma sürecini başlatır. Kabartma tozunu fırına attığımız keke ekleyemeyiz di mi? Çünkü fırına girdikten sonra kekin kabarması için geç kalmış oluruz. İşte constructor dışında eklediğimiz kurallar da aynen böyle, iş işten geçmiş oluyor. (Nesne çoktaan oluşturuldu kurallar olmadan :)) Constructor'a eklediğimiz kurallarla ise nesne doğru şekilde oluşturulabiliyor, çünkü kabartma tozunu ekleyerek kekimizin güzel bir şekilde kabarmasını sağladığımız gibi constructor'daki kurallarla nesnenin doğru bir şekilde oluşturulmasını sağlıyoruz. Afiyet olsun :))
İsimlendirme kuralları en önemli noktalardan biri olduğundan bahsedebiliriz ve isimlendirme yaparken bir başkası tarafından da kodun okunacağını göz önünde bulundurmamız gerekiyor dolayısıyla açıklayıcı olması ön plana çıkıyor diyebiliriz. PascalCase ya da camelCase olması ayrı bir avantajdır ki bunlar genellikle şirketlerin dökümantasyonlarında uyguladıkları kuralları olarak yer almaktadır. Yapıcı constructorın da referans type ile alakalı ve başka bir sınıf tarafından kullanılabilir olup default değerlerin orada tutulduğunu düşünüyorum.
Kısa ve kırpılmış isimler yerine, bir sınıfın ne işe yaradığını tam olarak anlatan isimler kullanmak her zaman daha iyidir. Çünkü kodu okuyan kişi, bu sayede neyin ne olduğunu daha kolay anlar. Yani, bir sınıfın ismi 5 kelimeyse ama tam anlamıyla ne işe yaradığını açıklıyorsa bu gayet normal. Ancak burada dikkat etmemiz gereken nokta, her zaman en basit ve net şekilde ifade etmeye çalışmaktır. Bir de beyin kelimeleri tek tek değil, bir bütün olarak algılar. Yani 5 kelimelik bir sınıf ismini de 2 kelimelik bir sınıf ismini de aynı hızda okuruz. Kullanılan yazım stili (örneğin, PascalCase) üzerinde tutarlı olmak da çok önemlidir. Bu sayede kod daha düzenli ve okunabilir hale gelir.
Öncelikle dikkat etmemiz gereken anlaşılır olması bence, başka bir kişi baktığında orada neyi tanımlamak istediğimizi anlamalı yani uzun isimlendirmeler daha anlaşılabilir olmasını sağlayabilir.
Uzun şekilde yazılması belki açıklayıcı olması, nerede ne işin yapıldığını anlamak için güzel olabilir ama örneğin burada ana klasörün ismini ValidationRules olarak vermişken tekrardan altındaki bir klasörün sonun ValidationRules ekinin olmasını ben kendimce çok uygun görmüyorum. Örneğin buradaki bir validasyon sınıfını kontrolörde çağırdığımız zaman using ifadesi çok uzun şekilde görünüyor ve bu göz yoruyor, belki bir ihtimal karışıklık yaratacak da olabilir. Bu sebeple ben ValidationRules altına AppUser, AppRole şeklinde klasör altına tanımlamalarımı yapar, klasör içindeki sınıflarıda AppUserValidator, AppRoleValidator şeklinde tanımlarım (öznel).
Öncelikle bu yoğun günlerinizde bize zaman ayırıp bu videoyu paylaştığınız için teşekkürler hocam, sorduğunuz sorula alakalı düşüncem ; dosyaların uzun isimli olmasıyla ilgili tek dezavantaj ismini yazarken yazım yanlışı yapmak olacaktır ki VS bunu bizim için dezavantaj olmaktan çıkarıyor. Uzun isimli olması projeye bir başkası baktığında veya kendi projemize uzun süre sonra baktığımızda anlaşılır, açıklayıcı olacak ve dosya yönetiminde kolaylık sağlayacaktır. Uzun isimle ilgili yaşadığım tek problem video izlerken ekranı 2'ye böldüğüm için Solition Explorer'da katman/dosya isimlerinin sığmamasından dolayı isimleri görebilmek için sağa sola gitmeye çalışmak 😅😅
bence açıklayı olması yalın olmasında açık ara daha iyi olur .Çok fazla dosya ya da proporties tanımlamış olabiliriz ve bu projeyi bir den fazla kişi çalışıyor olabilir daha kolay anlaşılmasını sağlar açıklayıcı olması
Bir Class çağırıldığında RAM' deki alanının oluşmasını sağlayan ve zorunlu olarak ilk çalışan metod Constructor metoddur. Biz yazmasak dahi bir class oluşturduğumuzda clasımız default ctora sahip oluyor. Ctor u somut olarak classımıza eklediğimizde AbstractValidator içerisindeki metodlar için aktif bir heap alanı açıyoruz ve o yüzden RuleFor u yazabiliyoruz diyebilir miyiz hocam.
Bana göre açıklayıcı olmalıdır. Eğer yalın hale indirgemek istersek, ileride bizim yerimize geçecek geliştiriciler belki de bunun neden böyle bir ada sahip olduğunu anlamayacaklar. Ne kadar uzun olursa olsun eğer yalın hali anlaşılmakta zorluk getirecekse, uzun ve açıklayıcı olması taraftarıyım. 2. sorunuzun yanıtını bilmediğim için araştıracağım ama tahminim şu yönde, consturctor'da yazabilmemizin sebebi nesne oluştuğunda direkt olarak bu kurallara da ulaşabilmemiz olabilir.
Sınıf isimlerinin uzun olması okunabilirlik ve çakışma açsından avantaj sağlar, ayrıca bu sayede işlevini daha iyi belirtmiş oluyoruz. Karıştırma riski daha az olur ve projeyi inceleyen herhangi biri daha kolay anlayabilir diye düşünüyorum. Dezavantajı da yazım hatası olabilir. FluentValidation ile ilgili sorunuzda internetten net bir cevap bulamadım, bir çok yazıda işlem sırası yazılmış neden kullanıldığına değinmemişler. Bir sonraki dersimizde nedenini anlatabilir misiniz? Emekleriniz için çok teşekkürler...
Çok uzun olmadığı sürece avantaj sağlayacaktır, küçük projeler açısından değilde büyük projeler düşüncesiyle ilerleyebilmek gerekiyor. Projenin class ve klasör isimlerini oluştururken başkalarının da anlayabileceği şekilde okunabilir ve anlaşılır olabilmesi daha iyi olacaktır. Bizden sonra da başka bir programlamacı arkadaş projenin başına gelebilir :)
Mümkün olan çerçevede açıklayıcı isimlendirmeler vermek projeyi başka bir developer mudahil olduğunda sorunun tespiti, anlaşılabilirlik gibi olayların performansı etkilemesinden doalayı bence açıklayıcı yazılmalıdır.
Constructor tanımlanmadığı durumlarda, doğrulama kuralları bir nesne örneği oluşturulmadan önce tanımlanmamış olur. Bu durumda, doğrulama kurallarına diğer sınıflar erişemezler ve doğrulama işlemi gerçekleştirilemez.
Bence hem yalın hem açıklayıcı olabilir. Ben olsam AppRole yazardım direkt. Hepsinin sonuna validation rules eklemeye gerek yok çünkü zaten hepsi validation rules adındaki bir üst klasörün altındalar.
Projelerimizin anlaşılır olması için verdiğimiz klasör ve class isimlerinin yalın olmasından çok açıklayıcı olmasının nerede ne yaptığımızı bilmemiz ve bir başkası baktığında da anlaması açısından daha önemli olduğunu düşünüyorum. Tabii 7 veya 8 kelimeden fazlası da aşırıya kaçabilir 😅
Elinize sağlık. ilk sorunuza cevaben klasör olsun class isimleri olsun ve değişken isimlerinin uzun olması şahsen karmaşık geliyor. kim neydi neredeydi bütün satırı kaplıyor.
bence değildir. yalın olmasından ziyade kodları başkası incelediği zaman rahat anlayabileceği bir yapı kurmamız daha önemli. ikinci soruda ise clientın girmiş olduğu veriyi kontrol etmesiyle alakalı olduğu için yapıcı metotta olması gerekiyor. Saygılar hocam sonraki dersi sabırsızlıkla bekliyoruz :)
Class isimleri ve Klasör isimleri kesinlikle açıklayıcı olmak zorunda eğer bizden sonra başka biri gelip koda bakar ve o classın ne olduğunu anlamazsa boşa bu kodları yazmışız demektir. SOLİD önemli
Emekleriniz için teşekkürler hocam. Mail kısmındaki kullanılan method mail içerisinde @ işaretinin olup olmadığına bakıyor olabilir mi? Bunun yanında @ işaretinden önce kullanılmaması gereken sembollerin ve sağında da yine kullanılmaması gereken sembollerinde kontrolünü yapıyor olabilir. Php ile patternler yazarken bu şekilde yapıyorduk.
Hocam bence Uzun olması dezavantaj değil anlaşılmaması dezavantaj o yüzden kısaltma kullanıpta anlaşılmayacağına anlaşılacak uzun isimlendirmeler sıkıntı olmayacaktır.
Öncelikle sınıf isimlerinin açıklayıcı olması daha doğru gibi geliyor,çünkü çalışma hayatında projelere daha sonra yeni kişiler katılabiliyor bu yüzden kodun okunabilirliği önemli. İkinici sorunuza gelirken de AbstractValidator sınıfı bir abstract class olduğu için içerisindeki metodlara ulaşmak istediğimizde yapıcı bir metodumuz yoksa ulaşamayız yapıcı metod bir nevi köprü görevi görüyor.
merhaba, ben bir hata aldım using ekleyince : the type or namespace name 'DtoLyer' does not exist in the namespace (are you missing an assembly reference ) ... nasıl düzeltebileceğim konusunda yardımcı olabilir misiniz
@@benmerve23 bu hatanın sebebi genellikle using kullandığın yere onun kütüphane ismini eklememenden kaynaklanıyor. Using'in üstüne gelip alt+enter yaparsanız gerekli namespace classa eklenecektir.
Arkadaşlarımın açıklamalarına katılıyorum, aşırıya kaçmamak kaydıyla kod okunurluğunu artırmak adına uzun isimlendirmenin problem oluşturacağını düşünmüyorum. RuleFor metodunun ctor içerisinde çağırılabilmesi konusunda aklıma dependency injection veya set özelliğinin sadece ctor da kullanılmasına izin vermesi geldi ne kadar doğru bilmiyorum
Merhaba hocam,(İnternetten araştırdım bende ezbere bilmiyordum): Bir yapıcı metot, o sınıfın yeni bir nesnesi oluşturulduğunda çalıştırılan, sınıfın özel bir metotudur. Bir yapıcı metot sınıf adıyla aynı isme sahiptir e-mail kontrolu için yazının içerisin de "@" yazmayı zorunlu hale getirirdim.
Hocam bence klasör ve class isimlerinin uzun olması başlangıçta daha okunamaz gibi gözüksede zamanla projeyi hem kendimizin hem de başkalarının daha kolay anlamasına imkan vereceğini düşünüyorum :)
Hocam, . the type or namespace name 'DtoLyer' does not exist in the namespace (are you missing an assembly reference ) hatası alıyorum, using ekleyince
email kısmı şu şekilde olmalı RuleFor(x => x.Email).EmailAddress().WithMessage("Lütfen geçerli bir email adresi giriniz"); fluent validator içindeki built in bu method ile kontrol sağlayabiliriz.
Merhaba. Hocam Junior bir yazılımcı olarak, yazılım sektöründe, hangisi literatüre daha uygun olur bilemem fakat şu aşamada benim için metot, klasör, interface ismi vb gibi tanımlamalar ne kadar uzun olursa o kadar iyi oluyor gerçekten :D
Açıklayıcı isimler kullanılması projeye sonradan katılan birisi için fayda sağlar. Fakat ben şöyle bir hatayla karşılaştım sınıf isimlerini uzun yazdığım için database aktarıma izin vermedi taki isimleri azalttım sonra aktarım sağladı. Böyle bir sorunla karşılaşan oldu mu?
Sınıf isimlerinin açıklayıcı olması, yalın olmasından önemli, ama 10 kelime de çok fazla olur, ona göre bazı kelimelerin kısaltmasıyla isim standardı oluşturulabilir. Projenin daha anlaşılır olmasını sağlıyor.
Yapıcı metodu genelde bir sınıfın referansında tutulacak default değerleri belirlemekte kullanıyoruz. Burada RuleFor'un yapıcı metotta olmasının sebebi kullanıcının girdiği değerle bu kuralı karşılaştırması olabilir.
teşekkürler
Ellerinize Sağlık hocam
FluentValidation: RuleFor()'un constructor içinde belirtilir çünkü bu sınıfın ilk oluşturulduğu anda doğrulama kurallarının tanımlanmasını sağlar. Yani bir sınıf örneği oluşturulduğunda doğrulama kurallarının hemen tanımlanmasına olanak sağlar ve bu nedenle bu kuralların sınıfın yaşam döngüsü boyunca geçerli olması sağlanır.
Emeğinize sağlık hocam, hayırlı cumalar
Emeğinize sağlık hocam...
Emeğinize sağlık hocam. Heyecanla yeni bölümleri bekliyorum 😊
Açıklayıcı olması yalın olmasından çok daha önemlidir. Bir proje de birden fazla kişi çalışabilir açıklayıcılık ön plana çıkmalıdır.
Burada Constructor(Yapıcı) metodu: AppUserRegisterDto sınıfına erişebilmek için bir nesne oluşturup ve bu oluşturulan nesneye otomatik olarak yapılmasını istediğimiz işlemleri yazıyoruz
Her ne kadar anlaşılması için yazılsa da uzun değişken isimleri, kodun okunabilirliğini zorlaştırabilir. Emeğinize sağlık hocam. Çok teşekkürler.
Constructorı kek yaparken kullandığımız bir kap gibi düşünelim. Tıpkı kek hamurunu karıştırmaya başlamadan önce kabartma tozunu eklediğimiz gibi nesneyi oluşturmaya başlarken de constructor içinde doğrulama kurallarını eklememiz gerekiyor. Çünkü constructor bir nesnenin oluşturulma sürecini başlatır.
Kabartma tozunu fırına attığımız keke ekleyemeyiz di mi? Çünkü fırına girdikten sonra kekin kabarması için geç kalmış oluruz. İşte constructor dışında eklediğimiz kurallar da aynen böyle, iş işten geçmiş oluyor. (Nesne çoktaan oluşturuldu kurallar olmadan :))
Constructor'a eklediğimiz kurallarla ise nesne doğru şekilde oluşturulabiliyor, çünkü kabartma tozunu ekleyerek kekimizin güzel bir şekilde kabarmasını sağladığımız gibi constructor'daki kurallarla nesnenin doğru bir şekilde oluşturulmasını sağlıyoruz. Afiyet olsun :))
İsimlendirme kuralları en önemli noktalardan biri olduğundan bahsedebiliriz ve isimlendirme yaparken bir başkası tarafından da kodun okunacağını göz önünde bulundurmamız gerekiyor dolayısıyla açıklayıcı olması ön plana çıkıyor diyebiliriz. PascalCase ya da camelCase olması ayrı bir avantajdır ki bunlar genellikle şirketlerin dökümantasyonlarında uyguladıkları kuralları olarak yer almaktadır.
Yapıcı constructorın da referans type ile alakalı ve başka bir sınıf tarafından kullanılabilir olup default değerlerin orada tutulduğunu düşünüyorum.
Kısa ve kırpılmış isimler yerine, bir sınıfın ne işe yaradığını tam olarak anlatan isimler kullanmak her zaman daha iyidir. Çünkü kodu okuyan kişi, bu sayede neyin ne olduğunu daha kolay anlar.
Yani, bir sınıfın ismi 5 kelimeyse ama tam anlamıyla ne işe yaradığını açıklıyorsa bu gayet normal. Ancak burada dikkat etmemiz gereken nokta, her zaman en basit ve net şekilde ifade etmeye çalışmaktır.
Bir de beyin kelimeleri tek tek değil, bir bütün olarak algılar. Yani 5 kelimelik bir sınıf ismini de 2 kelimelik bir sınıf ismini de aynı hızda okuruz. Kullanılan yazım stili (örneğin, PascalCase) üzerinde tutarlı olmak da çok önemlidir. Bu sayede kod daha düzenli ve okunabilir hale gelir.
Öncelikle dikkat etmemiz gereken anlaşılır olması bence, başka bir kişi baktığında orada neyi tanımlamak istediğimizi anlamalı yani uzun isimlendirmeler daha anlaşılabilir olmasını sağlayabilir.
Uzun şekilde yazılması belki açıklayıcı olması, nerede ne işin yapıldığını anlamak için güzel olabilir ama örneğin burada ana klasörün ismini ValidationRules olarak vermişken tekrardan altındaki bir klasörün sonun ValidationRules ekinin olmasını ben kendimce çok uygun görmüyorum. Örneğin buradaki bir validasyon sınıfını kontrolörde çağırdığımız zaman using ifadesi çok uzun şekilde görünüyor ve bu göz yoruyor, belki bir ihtimal karışıklık yaratacak da olabilir. Bu sebeple ben ValidationRules altına AppUser, AppRole şeklinde klasör altına tanımlamalarımı yapar, klasör içindeki sınıflarıda AppUserValidator, AppRoleValidator şeklinde tanımlarım (öznel).
Öncelikle bu yoğun günlerinizde bize zaman ayırıp bu videoyu paylaştığınız için teşekkürler hocam, sorduğunuz sorula alakalı düşüncem ; dosyaların uzun isimli olmasıyla ilgili tek dezavantaj ismini yazarken yazım yanlışı yapmak olacaktır ki VS bunu bizim için dezavantaj olmaktan çıkarıyor. Uzun isimli olması projeye bir başkası baktığında veya kendi projemize uzun süre sonra baktığımızda anlaşılır, açıklayıcı olacak ve dosya yönetiminde kolaylık sağlayacaktır.
Uzun isimle ilgili yaşadığım tek problem video izlerken ekranı 2'ye böldüğüm için Solition Explorer'da katman/dosya isimlerinin sığmamasından dolayı isimleri görebilmek için sağa sola gitmeye çalışmak 😅😅
bence açıklayı olması yalın olmasında açık ara daha iyi olur .Çok fazla dosya ya da proporties tanımlamış olabiliriz ve bu projeyi bir den fazla kişi çalışıyor olabilir daha kolay anlaşılmasını sağlar açıklayıcı olması
Bir Class çağırıldığında RAM' deki alanının oluşmasını sağlayan ve zorunlu olarak ilk çalışan metod Constructor metoddur.
Biz yazmasak dahi bir class oluşturduğumuzda clasımız default ctora sahip oluyor. Ctor u somut olarak classımıza eklediğimizde AbstractValidator içerisindeki metodlar için aktif bir heap alanı açıyoruz ve o yüzden RuleFor u yazabiliyoruz diyebilir miyiz hocam.
Bana göre açıklayıcı olmalıdır. Eğer yalın hale indirgemek istersek, ileride bizim yerimize geçecek geliştiriciler belki de bunun neden böyle bir ada sahip olduğunu anlamayacaklar. Ne kadar uzun olursa olsun eğer yalın hali anlaşılmakta zorluk getirecekse, uzun ve açıklayıcı olması taraftarıyım.
2. sorunuzun yanıtını bilmediğim için araştıracağım ama tahminim şu yönde, consturctor'da yazabilmemizin sebebi nesne oluştuğunda direkt olarak bu kurallara da ulaşabilmemiz olabilir.
Sınıf isimlerinin uzun olması okunabilirlik ve çakışma açsından avantaj sağlar, ayrıca bu sayede işlevini daha iyi belirtmiş oluyoruz. Karıştırma riski daha az olur ve projeyi inceleyen herhangi biri daha kolay anlayabilir diye düşünüyorum. Dezavantajı da yazım hatası olabilir.
FluentValidation ile ilgili sorunuzda internetten net bir cevap bulamadım, bir çok yazıda işlem sırası yazılmış neden kullanıldığına değinmemişler. Bir sonraki dersimizde nedenini anlatabilir misiniz?
Emekleriniz için çok teşekkürler...
Çok uzun olmadığı sürece avantaj sağlayacaktır, küçük projeler açısından değilde büyük projeler düşüncesiyle ilerleyebilmek gerekiyor. Projenin class ve klasör isimlerini oluştururken başkalarının da anlayabileceği şekilde okunabilir ve anlaşılır olabilmesi daha iyi olacaktır. Bizden sonra da başka bir programlamacı arkadaş projenin başına gelebilir :)
Mümkün olan çerçevede açıklayıcı isimlendirmeler vermek projeyi başka bir developer mudahil olduğunda sorunun tespiti, anlaşılabilirlik gibi olayların performansı etkilemesinden doalayı bence açıklayıcı yazılmalıdır.
Constructor tanımlanmadığı durumlarda, doğrulama kuralları bir nesne örneği oluşturulmadan önce tanımlanmamış olur. Bu durumda, doğrulama kurallarına diğer sınıflar erişemezler ve doğrulama işlemi gerçekleştirilemez.
Bence klasör adları ve class adları uzun olmalı en azından anlamlı olduğu zaman anlamamız dahada kolaylaşıyor yapıları daha düzgün kurabiliyoruz.
Bence hem yalın hem açıklayıcı olabilir. Ben olsam AppRole yazardım direkt. Hepsinin sonuna validation rules eklemeye gerek yok çünkü zaten hepsi validation rules adındaki bir üst klasörün altındalar.
projenin anlaşılması için ve yazılımcının avantajı için class isimleri ve değişkenleri ismi kısa ve açıklayıcı olması daha iyidir
Klasör isimlerinin kısa yalın olması yerine, açıklayıcı olması uzun yıllar sonra dönüp bakıldığında
daha avantajlı olabilir.
Projelerimizin anlaşılır olması için verdiğimiz klasör ve class isimlerinin yalın olmasından çok açıklayıcı olmasının nerede ne yaptığımızı bilmemiz ve bir başkası baktığında da anlaması açısından daha önemli olduğunu düşünüyorum. Tabii 7 veya 8 kelimeden fazlası da aşırıya kaçabilir 😅
Elinize sağlık. ilk sorunuza cevaben klasör olsun class isimleri olsun ve değişken isimlerinin uzun olması şahsen karmaşık geliyor. kim neydi neredeydi bütün satırı kaplıyor.
bence değildir. yalın olmasından ziyade kodları başkası incelediği zaman rahat anlayabileceği bir yapı kurmamız daha önemli. ikinci soruda ise clientın girmiş olduğu veriyi kontrol etmesiyle alakalı olduğu için yapıcı metotta olması gerekiyor. Saygılar hocam sonraki dersi sabırsızlıkla bekliyoruz :)
Hocam bence uzun isimler vermekte bir sakınca nacizane fikrim her klasöre tek tek validation rules yazmak yerine AppUserVR şeklinde bitirebiliriz
Hocam mehraba. Bir sorum olacakdr. IEntityTypeConfiguration kullanacak mısınız?
Class isimleri ve Klasör isimleri kesinlikle açıklayıcı olmak zorunda eğer bizden sonra başka biri gelip koda bakar ve o classın ne olduğunu anlamazsa boşa bu kodları yazmışız demektir. SOLİD önemli
Emekleriniz için teşekkürler hocam. Mail kısmındaki kullanılan method mail içerisinde @ işaretinin olup olmadığına bakıyor olabilir mi? Bunun yanında @ işaretinden önce kullanılmaması gereken sembollerin ve sağında da yine kullanılmaması gereken sembollerinde kontrolünü yapıyor olabilir. Php ile patternler yazarken bu şekilde yapıyorduk.
Hocam bence Uzun olması dezavantaj değil anlaşılmaması dezavantaj o yüzden kısaltma kullanıpta anlaşılmayacağına anlaşılacak uzun isimlendirmeler sıkıntı olmayacaktır.
Öncelikle sınıf isimlerinin açıklayıcı olması daha doğru gibi geliyor,çünkü çalışma hayatında projelere daha sonra yeni kişiler katılabiliyor bu yüzden kodun okunabilirliği önemli. İkinici sorunuza gelirken de AbstractValidator sınıfı bir abstract class olduğu için içerisindeki metodlara ulaşmak istediğimizde yapıcı bir metodumuz yoksa ulaşamayız yapıcı metod bir nevi köprü görevi görüyor.
merhaba, ben bir hata aldım using ekleyince : the type or namespace name 'DtoLyer' does not exist in the namespace (are you missing an assembly reference ) ... nasıl düzeltebileceğim konusunda yardımcı olabilir misiniz
@@benmerve23 bu hatanın sebebi genellikle using kullandığın yere onun kütüphane ismini eklememenden kaynaklanıyor. Using'in üstüne gelip alt+enter yaparsanız gerekli namespace classa eklenecektir.
@@bedranozcan hayır, using ekledim zaten, DtoLayer'i görmüyor BusinessLayer içinden
@@benmerve23 o zaman katmanlar arasındaki referans vermeyi unutmuş olabilirsiniz
@@bedranozcan 3.videodaki anlatımdan mı bahsediyorsunuz? acaba video dışı hocamız güncelleme mi yaptı? çünkü videolar ile birebir ilerliyorum
Arkadaşlarımın açıklamalarına katılıyorum, aşırıya kaçmamak kaydıyla kod okunurluğunu artırmak adına uzun isimlendirmenin problem oluşturacağını düşünmüyorum. RuleFor metodunun ctor içerisinde çağırılabilmesi konusunda aklıma dependency injection veya set özelliğinin sadece ctor da kullanılmasına izin vermesi geldi ne kadar doğru bilmiyorum
Merhaba hocam,(İnternetten araştırdım bende ezbere bilmiyordum): Bir yapıcı metot, o sınıfın yeni bir nesnesi oluşturulduğunda çalıştırılan, sınıfın özel bir metotudur. Bir yapıcı metot sınıf adıyla aynı isme sahiptir
e-mail kontrolu için yazının içerisin de "@" yazmayı zorunlu hale getirirdim.
Validation hatlarını kontrol etmek için sınıfı çağırınca ilgili ctor ilk olarak çalışıp hataları kontrol etmesi için olabilir gibi geldi. .d
Hocam bence klasör ve class isimlerinin uzun olması başlangıçta daha okunamaz gibi gözüksede zamanla projeyi hem kendimizin hem de başkalarının daha kolay anlamasına imkan vereceğini düşünüyorum :)
Hocam, . the type or namespace name 'DtoLyer' does not exist in the namespace (are you missing an assembly reference ) hatası alıyorum, using ekleyince
email kısmı şu şekilde olmalı RuleFor(x => x.Email).EmailAddress().WithMessage("Lütfen geçerli bir email adresi giriniz"); fluent validator içindeki built in bu method ile kontrol sağlayabiliriz.
video sonunda murat hocam anlatmış ben dökümantasyondan bakmıştım :)
Merhaba. Hocam Junior bir yazılımcı olarak, yazılım sektöründe, hangisi literatüre daha uygun olur bilemem fakat şu aşamada benim için metot, klasör, interface ismi vb gibi tanımlamalar ne kadar uzun olursa o kadar iyi oluyor gerçekten :D
veritabanına daha önce aynı isimden kaydedilmiş bir username var ise bunun kontrolünü nasıl yapabiliriz? teşekürler.
Hocam bu noktada async şekilde db'de bu kullanıcı adı veya email kayıtlı mı kontrolü yapılabiliyor mu?
E-mail kontrolü için regex ile match edebiliriz.
Hocam beyaz temaya güneş gözlüğü ile mi bakıyorsunuz😅😅
Açıklayıcı isimler kullanılması projeye sonradan katılan birisi için fayda sağlar.
Fakat ben şöyle bir hatayla karşılaştım sınıf isimlerini uzun yazdığım için database aktarıma izin vermedi taki isimleri azalttım sonra aktarım sağladı.
Böyle bir sorunla karşılaşan oldu mu?
RuleFor(x=>x.ConfirmPassword).Equals(x=>x.Password).WithMessage("Parola eslesmiyor!");
yerine
RuleFor(x=>x.ConfirmPassword).Matches(x=>x.Password).WithMessage("Parola eslesmiyor!");
kullanilabilir mi?
👨💻
Hocam Core Katmanına neden ihtiyaç duymadık
bunun cevabını buldunuz mu? ben de merak ediyorum
@@benmerve23 tamamen kişisel tercih ben kendi projeme ekledim
@@BayZweig core katmanında neler var ? ne eklediniz
using EasyCashIdentityProject.DtoLayer.Dtos.AppUserDtos;
eklenmediği için hata almıştım bilginize
@@benmerve23 Merhaba hatayı yollayabilir misiniz
ben de aynı hatayı almıştım. businesslayera dtolayerı refere etmediğimiz için. bunu düzeltirseniz sorununuz çözülür.