Laravel ile senior seviyede geliştirme yapanlar bir bakabilir mi

Merhabalar,

Bir sorum olacaktı. Laravel ile geliştirilen bir projede;

Controller içerisinde mi kod yazmak mantıklı
Yoksa Controller içerisinde yazacağımız kodları controller'da kullanmak yerine servis oluşturup(services provider) oradan controller'a dahil etmek mi mantıklı.(Tüm controller dosyaları için)

Maksat controller tarafında kod fazlalığını azaltıp hiç kod yazmayıp sadece servis katmanını kullanmak.

Bilgi verebilir misiniz? Teşekkürler.

aynı metodu tüm sayfalarda kullanacaksan ötabiiki sewrvis oluşturmak mantıklı ama sadece o controller dasoyası ise o controllerde kullanmak mantıklı

Controller-Service-Interface-Repository

veritabanı sorgularınıda ayır

SOLID kurallarını iyice bir araştırıp öğrenmeni tavsiye ederim, bu soruna kolaylıkla cevap alabilirsin öğrendikten sonra.

Tamamen projenin büyüklüğüne bağlı az öz proje ise gerek yok orta seviye ise evet olaylar büyükse domain driven design kullanmanı tavsiye ederim.

şöle açıklayayım projeden projeye göre değişiyor eğer bütün sayfalarda o veriyi kullanıcaksan ozaman service providerda oluşturabilirsin zaten service provider genelde bir sorguyu bütün sayfalarda kullanmamıza olanak tanıyor ama controllerın görevi farklı şimdi controllerda zaten bütün çoğu şeyi hatta laravelin %98 ini controller üzerinden yapıyorsunuz o yüzden projeye göre değişir yani hepsinin kullanım alanları farklı sevgilerle...

Benim önerim Repository Pattern kullanmak olur.

Detaylı eğitimlere bakarsın zaten kısa olarak bir anlatım buldum bunu inceleyebilirsin, ne olduğuna dair fikir verir.

https://www.youtube.com/watch?v=dcx9VecmvOE



Sorduğun soruya gelirsek ServiceProvider'ların kullanım amacı daha farklı.
Orada lojik oluşturmak çok mantıklı olmaz. Daha çok config/settings ayarlamaları, çeşitli tanımlamalar vs için kullanmak gerek serviceproviderları.

Selam,
Yazılım dünyasında over engineering ve antipattern diye de kavramlar var. Meslektaşlarımız, yazılımı bir kalıba sokmaya çalışarak aslında çok kısa sürede çok daha hızlı bir biçimde kod geliştirecekleri gerçeğinden uzaklaşıyorlar.

Over engineering ve antipattern konuları ise yine farklı prensip ile tasvir edilmeye çalışılmış; YAGNI ( you ain’t gonna need it - buna ihtiyacın olmayacak). Bu prensip ile baktığında, yazacağın kodun mimarisini tasarlayabilirsin. Herhangi bir ezbere kalıba kendini sokmadan.


Eğer kurumsal bir iş yapıyorsan yani; ekipçe kodun sürdürebilirliği sağlanıyorsa, teorikte anlatılan kalıplar geçerli olabiliyor. Bu sebeple hem kod kalitesini korumak hem de az önce bahsettiğimiz sürdürebilirliği korumak adına, koda harcanan eforu arttırmak mantıklı.

Özetlemek gerekirse, kendine bir proje geliştiriyorsan ve biraz daha sağlam temelleri olan bir mimari hedefliyorsan bilmen gereken konular SOLID’tir. Fakat solid bize herhangi bir mimariyi işaret etmez daha çok bir fikri aşılar.

Controller altına kod yazmak evet bakıldığında hoş gözükmez. Controllerin işini kabaca söylersek requesti alıp responseu vermektedir. Bir servis katmanına neden ihtiyaç duyuyoruz? Bunu düşünmemiz lazım. Herkes servis yapısı deyince kodu bir kere yazmak olarak tasvir eder. Aslında olay çok başka olabilir.

Konudaki özetle “servise taşıma” gereği bir ezber değil bahsetmiş olduğum SOLID metriklerine uymayı işaret eder. Interceptor, AOP, DI gibi mekanizmalara erişimi basitleştirir.

Controller genellikle business logic yapmayacak, yani business logic servisler tarafindan oluscak. Böylece daha iyi test edebilirsiniz servisleri ve controller'de az kod olur.

Lazim oldukca ona göre olustursunuz altyapiyi, ilk basta service, model, controller olusturup basliyabilirsiniz.

Ben Symfony kullaniyorum framework olarak, laravel'e hic gerek yok istedigim gibi yazabiliyorum kodu test yaziyorum calisiyor.
Hemde Anti-Patterns ve static methodlar nerdeyse yok.

Basit düsünün ki projenin bakimi ucuz ve kolay olsun, senior'in en büyük özelligi benim icin zor projeleri kolay kod'la cözendir.