Senaryoya uygun istek tipleri olmalıdır. Diğer türlü çoğunu post yapmak client'ı yoracaktır.
Elbette, Yanlış olarak gösterilen alandakiler de kullanılabilir fakat dışarıya açılan istekler Doğru kullanım alanında belirtildiği gibi olmalıdır ve genel olarak çoğul olmasına dikkat etmemiz gerekmektedir (Best Practices gereği).
| # | Metot | Doğru | Yanlış |
|---|---|---|---|
| 1 | Get | .../api/products | .../api/getproduct |
| 2 | Get | .../api/products/10 | .../api/getproductbyId |
| 3 | Post | .../api/products | .../api/saveproduct |
| 4 | Put | .../api/products | .../api/updateproduct |
| 5 | Delete | .../api/products/2 | .../api/deleteproduct |
| # | Kod | Açıklaması |
|---|---|---|
| 1 | 200 Ok | İşlem Başarılıysa bu kod dönmelidir. |
| 2 | 201 Created | Yeni kayıtlarda burası dönmelidir. |
| 3 | 204 NoContent | İstek başarılı fakat cevap dönmediğini belirtir. Bu durum kodunu Put (güncellemelerde) ve Delete (silme) isteklerinde kullanmamız gerekmektedir. |
| 4 | 400 BadRequest | Eksik istek gibi durumlarda bu kod dönmelidir. |
| 5 | 401 Unauthorized | Server tarafında herhangi bir güvenlik kontrolünü sağlamaıyorsa (yetki kısıtlaması), (token vs.) bu kod dönmelidir. |
| 6 | 403 Forbid | Token doğru fakat istek atılan endpoint'e yetkisi yoksa, bu hata kodu dönmelidir. |
| 6 | 404 NotFound | İşlem yapılmak istenen veri VT de yoksa, bu hata kodu dönmelidir. |
| 7 | 500 Internal Server Error | Server tarafında hata gerçekleştiği zaman bu hata kodu dönmelidir. |
- Uygulamayı küçük parçalara bölün.
- Action metotlarında business kodu olmamalıdır.
- Action metotlarının içinde try cache blokları olmamalı.
⭐ Hatalar tek bir yerden kontrol edilmelidir.
- Action metotlar içinde kod tekrarından kaçının.
⭐ Örnek: ValidationFilter attribute'u kullunmak, id ile gtirme işlemi action metodunda birden fazla yerde çağırılıyorsa, ServiceFilter attribute'u yazılabilir.
- Action metotlarına mode sınıflarımızı dönmemeiz gerekmektedir. DTO sınıfları dönülmelidir.
🌟 Benim görüşüme göre; belki de şu şekilde değerlendirmemiz gerekmekte, eğer model sınıfını geri döndüğümüzü varsayarsak, dışarıya vt'deki kolon isimlerini geri dönmüş olacağız. Böylelikle, bir güvenlik zafiyeti oluşturmuş olacağız. Bunu önlemek adına DTO snıfları kullanmak daha mantıklı olacaktır.
- Core Katmanı
Projenin çekirdeğini oluşturmaktadır. Model(Entity), DTO, Repository Interface, Service Interface, UnitOfWork Interfaces
- Repository Katmanı
Migration, Seeds, Repository Implementation, UnitOfWork Implementation
- Caching
- Service Katmanı
Bussiness kodları olmalıdır. Mapping, Service Implementation, Validations, Exceptions
- API Katmanı
- Web Katmanı
Minimal Hosting Model:
- Bir uygulama oluşturmak için dosya ve kod satırlarının sayısını önemli ölçüde azaltır.
- Startup.cs ve Program.cs dosyalarını tek dosyada, Program.cs de birleştirir.
- Bir uygulama için gereken kodu en aza indirmek için üst düzey ifadeleri kullanır.
- Gereken kullanım ifadesi satırlarının sayısını ortadan kaldırmak veya en aza indirmek için genel kullanma yönergelerini kullanır.
🔔 Web App template inde de bir kaç değişiklik olmuştur.
- Index.cshtml ve Privacy.cshtml using statement ı kaldırıldı.
- Error.cshtml de RequestId nullable yapıldı.
- appsettings.json ve appsettings.Development.json dan "Microsoft.Hosting.Lifetime": "Information" satır kaldrıldı.
⭐ Program.cs, Startup sınıfının yaşama süresini ve somutlaştırmasını kontrol eder.
⭐ Configure yöntemine eklenen tüm ek hizmetlerin Program sınıfı tarafından manuel olarak çözülmesi gerekir.
VT ye yapılacak işlemleri toplu bir şekilde tek bir transaction üzerinden yönetmemizi sağlar.
SaveChanges() diyene kadar ef bunu memory de tutar.
Bu metodu kontrol altına alınması lazım. Bunu sağlayacak olan IUnitOfWork sağlayacaktır. Eğer Bu pattern olmasaydı; veri kaybı yapılabilirdi.Yapılan herhangi bir hatada, tüm işlemleri geri almayı, transaction yapmayı ef core yapacaktır.
DTO sınıfları, Core katmanında yazılmalıdır. Çünkü, Core katmanı tüm katmalarda var ve DTO'lar da tüm katmanlarda kullanılmak istenebilir.
Bu projede Fluent Validation kullanılmıştır. Önce, bu validasyona özel sınıfımızı oluşturduk.Koda Git
Sonrasında bunu hata mesajlarını kendi özel cevabımızda dönmemiz gerekecektir.
Koda Git
Yazmış olduğumuz bu özel cevabı Core'a bildirmemiz gerekiyor.
Program.cs in içine;
//Validator ü ekliyoruz
builder.Services.AddControllers(options => options.Filters.Add(new ValidateFilterAttribute())).AddFluentValidation(x=>x.RegisterValidatorsFromAssemblyContaining());
//Filter için kendi özel sınıfımızı yazdık ve bunu bildiirmemiz gerekiyor servisimize eğer bildirmezsek fluent in validation'ını kullanacaktır.
builder.Services.Configure(options =>
{
options.SuppressModelStateInvalidFilter = true;
});
⭐ Eğer bir filter'ınız constructor'ında parametre istiyorsa, bunu Program.cs'de belirtmemiz gerekir.
builder.Services.AddScoped(typeof(NotFoundFilter<>));
Bu filter'ı kullanabilmemiz için attribute şeklinde yazarken, ServiceFilter kullanılmalıdır. Çünkü bizim filter'imiz generic bir yapı ve bir tip istemekte.
Örnek:
[ServiceFilter(typeof(NotFoundFilter))]