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.
İ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.
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 :))
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ı
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...
Ö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.
Ö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 😅😅
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).
Ç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 :)
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
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.
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.
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.
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 😅
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.
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
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.
Ö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.
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.
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 :)
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.
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.
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 :)
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.
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.
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
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
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?
Hocam, . the type or namespace name 'DtoLyer' does not exist in the namespace (are you missing an assembly reference ) hatası alıyorum, using ekleyince
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.
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.
Emeğinize sağlık hocam, hayırlı cumalar
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.
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.
İ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.
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 :))
Bu kadar basit açıkladığın için teşekkürler. Hayatım boyunca unutmam artık :D
Emeğinize sağlık hocam. Heyecanla yeni bölümleri bekliyorum 😊
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ı
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...
Ö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.
Ö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 😅😅
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).
Emeğinize sağlık hocam...
Hocam Sonradan Gelcek Programcılar için Açıklayıcı olması önemli ama kısaltmalar yaparak bunu minimilimize edebiliriz
Ç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 :)
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
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.
Ellerinize Sağlık hocam
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.
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.
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.
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 😅
Hocam bence uzun isimler vermekte bir sakınca nacizane fikrim her klasöre tek tek validation rules yazmak yerine AppUserVR şeklinde bitirebiliriz
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
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.
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
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.
Hocam mehraba. Bir sorum olacakdr. IEntityTypeConfiguration kullanacak mısınız?
Ö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
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 :)
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 :)
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.
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.
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 :)
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
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.
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.
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
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
E-mail kontrolü için regex ile match edebiliriz.
Hocam beyaz temaya güneş gözlüğü ile mi bakıyorsunuz😅😅
veritabanına daha önce aynı isimden kaydedilmiş bir username var ise bunun kontrolünü nasıl yapabiliriz? teşekürler.
🤔 very nice
teşekkürler
Hocam bu noktada async şekilde db'de bu kullanıcı adı veya email kayıtlı mı kontrolü yapılabiliyor mu?
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?
Hocam, . the type or namespace name 'DtoLyer' does not exist in the namespace (are you missing an assembly reference ) hatası alıyorum, using ekleyince
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
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?
👨💻
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.