Bunun için internette dolaştım, ancak Django'nun "uygulamalar" olarak tanımladığı şeyle ilgili hala sorun yaşıyorum.
Ana projedeki modelleri kullanıyor olsa bile, bir sitedeki her bir işlevsellik parçası için yeni bir uygulama oluşturmalı mıyım?
Yeni bir uygulamayı ne zaman ayıracağınız ve işlevi ne zaman "ana proje" veya diğer uygulamalarla bir arada tutacağınız konusunda iyi bir kuralınız var mı?
Yanıtlar:
James Bennett'in Django'da yeniden kullanılabilir uygulamaların nasıl organize edileceğine dair harika bir slayt seti var .
Django uygulamalarını "uygulamalar" yerine yeniden kullanılabilir modüller veya bileşenler olarak düşünmeyi tercih ederim.
Bu, belirli özellikleri birbirlerinden ayırmama ve ayırmama yardımcı oluyor, belirli bir "uygulamayı" toplulukla genel olarak paylaşmaya karar verirsem yeniden kullanılabilirliği ve sürdürülebilirliği artırıyor.
Genel yaklaşımım, belirli özellikleri veya özellik gruplarını, sanki bunları herkese açık olarak yayınlayacakmışım gibi "uygulamalar" halinde toplamaktır. Buradaki zor kısım, her bir kovanın ne kadar büyük olduğunu bulmaktır.
Kullandığım iyi bir numara, uygulamalarımın herkese açık olarak yayınlanırsa nasıl kullanılacağını hayal etmektir. Bu genellikle beni kovaları küçültmeye ve "amacını" daha net bir şekilde tanımlamaya teşvik ediyor.
İşte 6 Eylül 2008'deki güncellenmiş sunum.
DjangoCon 2008: Yeniden Kullanılabilir Uygulamalar @ 7: 53
Slayttan alınmıştır
Bu kendi uygulaması mı olmalı?
- Uygulamanın odak noktasıyla tamamen alakasız mı?
- Yaptığım başka her şeye ortogonal mi?
- Diğer sitelerde benzer işlevlere ihtiyacım olacak mı?
Bunlardan herhangi biri "Evet" ise? O zaman en iyisi onu ayrı bir uygulamaya bölmek.
İnternette bulduğum bu sorunun en iyi iki cevabı:
Her iki kaynak da aşağıdaki durumlarda ayrı bir uygulama oluşturmanız gerektiği konusunda hemfikirdir:
Bir 'uygulama' birçok farklı şey olabilir, hepsi gerçekten tadı düşüyor. Örneğin, bir blog oluşturduğunuzu varsayalım. Uygulamanız blogun tamamı olabilir veya bir 'yönetici' uygulamasına, tüm genel görünümler için bir 'site' uygulamasına, bir 'rss' uygulamasına, bir 'hizmetler' uygulamasına sahip olabilirsiniz, böylece geliştiriciler kendi blog'larına kendi yolları vb.
Ben şahsen blogun kendisini bir uygulama yapardım ve içindeki işlevselliği ortaya çıkarırdım. Blog daha sonra diğer web sitelerinde oldukça kolay bir şekilde yeniden kullanılabilir.
Django'nun güzel yanı, dizin ağacınızın herhangi bir düzeyindeki tüm models.py dosyalarını Django modellerini içeren bir dosya olarak tanıyacak olmasıdır. Dolayısıyla, bir "uygulama" içinde işlevselliğinizi daha küçük "alt uygulamalara" bölmek, hiçbir şeyi daha zor hale getirmez.
Bu sorunun en iyi cevabı Andrew Godwin (Django çekirdek geliştiricisi) tarafından verilmektedir:
Bence uygulamaların temel amacı, yeniden kullanılabilir bileşenlerin mantıksal olarak ayrılmasını sağlamaktır - özellikle modeller / admin / vb. İçin birinci sınıf bir ad alanı. - ve her şeyi "açmak" veya "kapatmak" için kolay bir yol sağlamak.
Bazı açılardan bu, Django'nun yaratıldığı zamanın bir kalıntısıdır - Python paketleme ve modülleri çok daha az geliştiğinde ve temelde soruna kendi çözümünüze sahip olmanız gerektiğinde. Bununla birlikte, yine de Django'nun zihinsel modelinin temel bir parçası ve INSTALLED_APPS'nin hala Python'un alternatif giriş noktaları teklifinden daha temiz ve daha kolay bir çözüm olduğunu düşünüyorum (bu, bir ortamda yüklü olan ancak sizin yapmadığınız bir paketi devre dışı bırakmayı oldukça zorlaştırıyor. kullanmak istemiyorum).
Bugün uygulama konseptinden özellikle ayrıştırılabileceğini düşündüğünüz bir şey var mı? Modeller ve yöneticinin otomatik keşif ve benzersiz bir ad alanı öneki için buna ihtiyacı var, bu yüzden bunu geri almak zor ve ihtiyacınız olan diğer özellikleri düşünmekte zorlanıyorum (aslında, istediğiniz tek şey sadece bir kitaplıksa, bunu yapabilirsiniz normal bir Python - modelleri, şablonları veya IIRC yönetici kodunu göndermediğiniz sürece uygulama sarmalamaya gerek yoktur)