PHP ile büyük bir web uygulaması oluştururken bir çerçeveden kaçınmak mantıklı mı?

Birkaç yıldır bir PHP web uygulaması geliştiricisi olarak, MVC'ler ve çerçevelerden payımı aldım. İlk başta ekmek dilimlendikten sonra en iyi şey olduklarını düşündüm; her şeyin uygulanması çok kolay görünüyordu.

Ancak şimdi, uygulama ne kadar karmaşık hale gelirse, çerçeve o kadar zorlanır, bu yüzden bunları aşmak için geçici çözümler geliştirmem gerekir. Bu tür geçici çözümler genellikle göz korkutucu ve karmaşıktır, çünkü çerçeve çekirdek kodunu incelemek ve istediğim gibi davranması için değişiklikler yapmak zorundayım.

Örneğin, Slim (C) + Idiorm (M) + Twig (V) kullandığım projelerimden birinde (ki çok esnek olduğuna inanıyorum), yalnızca ana şablonlarda dinamik verileri görüntülemek için özel bir işlev oluşturmam gerekiyor; bir çerçeve olmadan ben sadece dahil edilen dosyada mysql_query () yürütmüş olabilir.

Tamam, basit bir şirket profili web sitesi oluşturursam çerçeveler harika; Bir gecede bazı kodları çırpabilirim ve genellikle sabah hazır olurlar ve onlardan öğrendiğim iyi kodlama uygulaması ve tasarım desenleri çok değerlidir.

Ama gerçekten, hepsi bir arada web tabanlı okul yönetim sistemi gibi karmaşık bir web uygulaması için, çerçeveler genellikle yukarıdaki örnekte olduğu gibi iş sürecimin önüne geçer.

Yani sorum şu: yeterince iyi kodlama uygulamalarını ve makul tasarım modellerini takip edebilmem şartıyla, temellere geri dönmenin ve bir sonraki projemi yapmak için standart PHP kodunu ve liberies'i kullanmam uygun mu? MVC gibi mi? Geliştirme ekibim oldukça küçük: sadece 2 programcı ve 1 tasarımcı. Diğer programcı yukarıdaki düşüncelerime katılıyor.

Benim deneyimim senin tam tersi. Küçük, hızlı şeyler yaparken, kodunuzu belirli bir şekilde yerleştirmeniz ve devam etmeden önce dikkatlice düşünmeniz gereken bir çerçeve biraz "yoluna girebilir". Sadece doğrudan zıplayarak mysql_queryprototipinizin daha hızlı çalışmasını sağlayabilirsiniz.

Ancak büyük, karmaşık siteler için, dikkatli bir şekilde kod düzenlemek ve kodunuzu nasıl yazacağınızı gerçekten düşünmek, ileride bakımı yapılacak bir site istiyorsanız son derece önemlidir.

Özellikle, mysql_querysayfa döngüsünün rastgele bölümlerine çağrı eklemek genellikle gerçekten kötü bir fikirdir. Burada bir tane olabilir ve başlamak için bir tane olabilir ve bu çok önemli değil, ama çok geçmeden her yere düzine yayılmış olacaksınız ve sayfalarınızın neden yalnızca 3 saniye sürdüğünü merak ediyorsunuz. Ya da şemanızı ve görünüşte alakasız bölümlerini bilinmeyen nedenlerle değiştirirsiniz.

Bence bir çerçeve sadece geliştirme sürecini sizin için kolaylaştırır ve hantal değil ise kullanılmalıdır. Özellikle küçük projeler için bir çerçeve kullanmamanız veya kendi çerçevenizi oluşturmamanız yanlış bir şey değildir.

Açıkçası, yapı ve güvenlik yönlerine dikkat etmeniz gerekecek, ancak yıllardır çerçeveler kullandığınızı düşünürseniz, muhtemelen bu yönleri içeriden biliyorsunuzdur.

Daha büyük projeler için diğerlerine katılıyorum, yani bir çerçeve kullanmanın muhtemelen uzun vadede en iyi seçenek olacağı anlamına geliyor.

Sunucu tarafı "çerçeveleri" ile yaşadığım deneyimler oldukça rahatsız edici oldu, örneğin:

A) Çerçevelerin birbirinizle veya uygulama sunucusuyla istemediğiniz ve hakkında bir şey bilmediğiniz ve hiçbir şey bilmediğiniz şeylerin karşılıklı uyumsuz sürümleri için çakıştığı, birden çok sunucu.

B) En basit nesne oluşturma işleminin binlerce gereksiz SQL uygulamasına felaketle patlaması.

C) 100 satır XML kodlamanın 2 satır Java kodlamasından bir şekilde daha kolay veya daha güvenilir olduğu garip düşüncesi.

D) İstemci tarafı nesnelerine başka bir veya bazen birden çok başka dilde (C # JS vb.) Eşlemek için tamamen gereksiz sunucu tarafı POJOS'un 100'lü satırlarını yazma ihtiyacı

E) Çerçeveyi çağırmak için kullandığınız kod satırını bile içermeyen 30 seviyeli derin yığın izini aldığınızda gerçekten ne olduğuna dair bir ipucu yok.

Bir dönek olun, kendi çerçevenizi yazın ... önce diğerlerinin sizi düşünmeye kandırdığı tüm gereksiz şeyleri ortadan kaldırmayı planladığınız sürece pişman olmayacaksınız. Sonra hepsini anlayacaksınız, Mb yerine Kb ile gönderilecek ve muhtemelen Java'nın kurucu ilkelerinden biri olan "herhangi bir yerde" çalışacak değil mi?

"Neden buna ihtiyacım var ... sadece çerçeveyi mutlu etmek mi?" Diye düşünmeye çalışın. .. Buna ihtiyacım yoksa, başka neye ihtiyacım yok?

Django geliştiricileri tarafından şu anda bulmakta zorlandığım bir sunum yolu vardı, ancak bir çerçevenin sizi daha üretken hale getirdiği "verimlilik vadisi" hakkında konuşuyorlar.

Bir projeye başladığınızda çerçeve hakkında hiçbir bilginiz olmadığını varsayarsak, verimliliğiniz başlangıçta çok düşük olacaktır - dilin deyiminden ziyade çerçevenin kurallarını öğreneceksiniz (umarım zaten biliyorsunuzdur).

Kısa bir süre sonra, sözleşmeleri kabul etmiş olacaksınız ve burası çerçevelerin gerçekten parladığı yer - aniden verimliliğiniz çatıdan geçiyor ve geliştirme yoluyla ilerliyorsunuz ve inanılmaz bir hız.

Sonunda, proje öyle bir boyutta olacak ki, çerçeve bir nimetten daha kısıtlayıcı olacak ve bazı özellikleri denemek ve uygulamak için kendinizi çerçeveye korkutuyor göreceksiniz.

Sunumda, elbette çerçevenin sözleşmeleri hakkında bilginiz varsa, daha küçük boyutlu projelerin verimlilikte ilk engel olmadığını belirtiyorlar.

Bu nedenle, küçük projeler için (benim tecrübelerime göre, ~ 500 saatin altındaki herhangi bir şey), bir çerçevedeki verimliliğiniz, olmadan verimliliğinizden daha büyük olacaktır. Belirli bir eşik değerine girdikten sonra (500 ile 800 saat arasında, IME), çerçevenin sunabileceği sınırlamalar olduğunu fark etmeye başlarsınız.

Bununla birlikte, çerçeveler sadece verimlilikten çok daha fazla fayda sağlar - Symfony veya Django veya (sanırım) Rails, bir ekibin dinamik olarak esnemesini sağlayan ve ayrıca müşterilerin veya ürün sahiplerinin personelini ihtiyaç duymadan personelini değiştirmesine izin veren bir sözleşme sağlar yeni bir sistemi tamamen yeniden tanımlamak için yeni kaynak - eğer bir çerçeve konvansiyonuna aşinalarsa ve bu sözleşme izlendiyse, başlangıçta diğerlerinden çok daha üretken olacaklardır.

İyi tasarlanmış bir çerçeve, bir engel değil, programcıya yardımcı olmalıdır. Kullandığınız çerçeve çok fazla yol alıyorsa, farklı bir çerçeveye bakmanızı öneririm. Her birinin kendi kodlama stili ve kendi artıları ve eksileri vardır.

Bunu söyledikten sonra, Zend çerçevesi bu günlerde ve dürüstçe çılgınca popüler görünüyor mu? Nedenini bazen görmek için mücadele ediyorum. Geçmişte bununla çalışmak zorunda kaldım ve mimarisini biraz sevmedim. Zend_Form sınıfı gülünç bir şekilde değiştirildi, dekoratör sistemi kullanımda tamamen korkunç ve dekoratörler formları görünümlere bağlayarak nesnelerin gevşek bir şekilde birleştirilmesi gerektiğini belirten temel bir OOP kavramını kırıyorlar. Ayrıca tek tonlar olarak uygulanan bir çok kodu vardır (bu da tekrarlanmayacak şekilde iyi belgelenmiş nedenlerden dolayı kötüdür) ve Registry nesnesi de özensiz bir kodlama stilini teşvik etmeye katkıda bulunur.

Zend Framework 2'nin (şu anda beta sürümünde) çok daha iyi bir ürün olduğunu duydum, ancak Zend 1'in ağzımda bıraktığı kötü tat, denemek için acelem olmadığım anlamına geliyor.

Yine de, bu noktada sadece koşuyorum. :) Orada her biri artılarını ve eksilerini olan birçok çerçeve var, birkaçını değerlendirmenizi öneririm.

Açıkladığınız şey geçmişte "soyutlamaya bağlı karmaşıklık" olarak adlandırılmıştı. Bunu yönetmeyle ilgili tek makale: Soyutlamaya Dayalı Karmaşıklığı Yönetmek , David Keppel. Keppel, çerçevelerin soyutlamaya bağlı karmaşıklığa neden olan bir tasarıma sahip olduğunu önerecektir.

Bir çerçeveyle çalışmak , tekerleği yeniden icat etmeyerek gelişiminizi hızlandırmanıza yardımcı olur . Framework ayrıca uygulamanızı düzgün bir şekilde tasarlamanıza yardımcı olacak araçlar sağlar (ancak veritabanına doğrudan görünümden erişmeniz gibi kötü tasarım kararları almanızı engellemez).

Bazen özel bir işleve ihtiyaç duyduğunuzda, düzgün bir şekilde yazılması daha uzun sürebilir. Ancak sürekli olarak bilgisayar korsanlığı yapıyor ve geçici çözümler buluyorsanız, çerçeveye karşı çalışıyorsunuz veya çerçeve ihtiyaçlarınızı karşılamıyor.

Sonuç olarak, basit projeler için büyük bir çerçeve kullanmak (örneğin bir veritabanından birkaç alan görüntülemek) bazen aşırıya kaçabilir. Büyük veya karmaşık projeler için bir çerçeve kullanın.

Kendi kodunuzu yazmanın ve bir Framework'ü kullanmanın birden fazla tarafı vardır:

Birlikte çalıştığınız ekibin boyutu, temel bilgisi ve deneyimi : Eğer hiçbir zaman bir çerçeve kullanmamışlarsa veya bir uygulamayı nasıl tasarlayacaklarına dair bir fikirleri varsa, çok sayıda örneği olan iyi belgelenmiş bir çerçeveyle daha iyisiniz ve onları hızlandırdığınızı görüyorsunuz. yukarı.

Uygulamanın boyutu : Sen hiç o nasıl kullanılacağını önceden biliyorum. Yani büyümeye ve değişmeye hazır olsan iyi olur. Bir gecede kodlamak istediğiniz çerçeveniz yönetimin ihtiyaçları ile birlikte büyüyebilir mi? DB alan türlerini değiştirmek ve uygulamak için bir dakika veya bir gün sürer, bu benim burada nokta.

Hazırlık : Bir çerçeve kullanıyorsanız, uygulamanızın çekirdeğini kodlamak yerine uygulamayı tasarlamaya başlayabilirsiniz, güvenlik ve dağıtımın önemli parçalar olduğu bir çerçeve kullanın , bu çok zaman alır. Her zaman.

Ben her zaman "geliştirme" ile web geliştirme için bir çerçeve olduğundan Symfony2 kullanmak için tartışıyorum. Yönetim bunun büyük olduğunu düşünüyor, öğrenme eğrisi dik olduğu için paraya mal olacak ve programcıları utandıracak.

Çerçeveler, moderndeki herhangi bir dil için, özellikle büyük projeler için hala kullanılacaktır. Bir proje büyüdükçe bir çerçeve daha önemli hale gelir, bu yüzden mantığın her şey için nerede olduğunu bilirsiniz ve her özellik benzer bir düzene sahiptir. Tüm veri erişimini veya tüm sunumu nerede arayacağınızı veya iş kurallarının nerede yönetildiğini bildiğinizde bir projeyi değiştirmeyi ve öğrenmeyi kolaylaştırır.

Yine de, projeye uyan bir çerçeve seçmek gerekir, bir kurumsal çözüm, kurumsal yetenekli bir çerçeve gerektirir. PHP kullanırken karşılaşacağınız problem budur. Birçok (çoğu) çerçeve büyük ölçekte kullanılmak üzere tasarlanmamıştır, ancak daha küçük kişisel siteler için iyi çalışırlar. Bahsettiğiniz okul yönetim sistemi gibi bir şey için, daha sağlam bir çerçeve gerektirecektir ve PHP'de uygun bir çerçeve bulmak biraz zaman alabilir.