Delphi'de, projelerime paylaşılan bir pakete paylaşılan birimleri mi eklememeliyim?

Question

Bu soru this one ile benzerdir, ancak bu soruda ele alınmayan sorunları sorduğum için yinelenmez.

\MyApp 
    \MyClientApp 
    \MyServerApp 
    \lib 

2 gerçek Delphi projeleri (.dpr), MyClientApp ve MyServerApp klasörlerinde birer vardır:

Ben şu dizin yapısı ile Delphi 7'de bir istemci-sunucu projesi var.

Lib klasöründe, istemci ve sunucu uygulamaları için ortak kod bulunan .pas birimleri bulunur. Merak ettiğim şey, bu .pas dosyalarını istemci ve sunucu projelerine eklemem gerekirse? Veya lib klasöründe bu birimleri içeren bir paket oluşturmalı mıyım? Ya da lib klasöründe oturan .pas dosyalarını bırakıp herhangi bir uygulamaya/pakete eklememeli miyim?

Her yaklaşımın artıları/eksileri nelerdir? Hangi yol "en iyi"? Lib klasöründen bu birimlerin birden fazla projeye dahil edilmesine ilişkin herhangi bir sorun var mı?

Şu anda lib klasöründeki birimler herhangi bir uygulamanın/paketin parçası değildir. Bunun bir dezavantajı, örneğin, istemci uygulamamın Delphi'de açık olması ve bir şey için projedeki tüm dosyaları aramak istediğimde, lib klasöründeki birimlerde de arama yapmamasıdır. Bu birimleri açarak ve tüm açık dosyalarda bir arama yaparak veya grep arama kullanarak (ama daha iyi bir çözüm tercih ederim) bunu aştım.

Ayrıca, lib klasöründeki bu dosyalar üzerinde değişiklik yaptığımda (proje grubu kullanmam gerekir mi?), Ayrı bir paket açıp yeniden açmam gerekmediği bir çözümü de tercih ederim.

Answer 1

Uygulamalar arasında birimlerin paylaşımı, her zaman diğerini bozan bir uygulamada yapılan uyumsuz değişikliklerin riskini taşır. Öte yandan, bu birimlerin kopyalarını yapmak daha da kötüsüdür, bu yüzden onları kendi alt dizinlerine taşımanızın yaklaşımı, en azından diğer programları dikkate almadan değiştirmeye psikolojik bir engel katar.

Proje dosyalarına eklendiklerinde: Genellikle IDE'den projeye sık sık erişmekte olan (genişletmek veya başvurmak için) bazı birimleri ekliyorum ve diğerlerini arama yolunu kullanarak derleyici için dışarıda bırakıyorum. . Bunu proje bazında yapıyorum, bazı birimler birkaç projenin parçası olabilir, neden olmasın?

Paket halinde bir uygulama oluşturmak istiyorsanız, bunları bir pakete koymanız mantıklıdır, aksi halde, neden rahatsız olur? Benim proje ve kütüphanelerin düzenlemek konusunda daha fazla bilgi için

, http://www.dummzeuch.de/delphi/subversion/english.html

Answer 2

Genellikle tüm paylaşılan birimlerle bir paket oluşturur ve yalnızca birimleri kullanırım. "Çalıştırma zamanı paketleri ile oluştur" seçeneğini açıkça işaretlemezseniz, paket içeriği (tüm kullanılan dcu'lar) projenize başka bir birim olarak bağlanır.

Answer 3

Projeler tarafından paylaşılan dosyalardan hoşlanmıyorum. Çoğu zaman, paylaşılan dosyalardan birini düzenlemek için cazip olacaksınız ve diğer projede bir şeyleri kıracaksınız ya da diğer projeyi yeniden yapmanız gerektiğini unutacaksınız.

Paylaşılan dosyalar kendi kitaplıklarına (paketlerine) ayrıldığında, bunları düzenlemek için biraz daha fazla engel var. Bunu iyi bir şey olarak düşünüyorum. Projeye özel koddan paylaşılan koda geçiş yaptığınızda hafif bir hatırlatma olacaktır. Her bir tek IDE örneğinde bir arada kalmanıza izin vermek için proje gruplarını kullanabilirsiniz. Kütüphane projelerini çalıştırılabilir projelerin önünden düzenlemek. "Tümü oluştur" komutu, ilk projeden başlayarak her şeyi sırayla kuracaktır.

DCU dosyalarınızı PAS dosyalarınızdan ayrı tutun. Paketinizin birimlerini başka bir yere göndermek için "DCU çıkış dizini" proje seçeneğini belirleyerek bunu kolayca yapabilirsiniz. Ardından bu hedef dizini diğer projelerinizin "arama yoluna" yerleştirin. DCU'yu bulacaklar, ancak PAS dosyasını bulamayacaklar ve başka hiçbir proje yanlışlıkla üye olmayan bir birimi yeniden derleyemez. Ayrı bir pakete sahip olmak ayrıca, projeye özgü koşullu tanımların kullanılmasını da teşvik etmemektedir. Projeler arasında birimler paylaşırken bunlar her türlü soruna neden olur. Projeye özgü tüm seçenekleri ilgili projeler içerisinde tutmanın bir yolunu bulun. Paylaşılan bir kütüphane, projeye özgü değişiklikler gerektirmemelidir. Bir kütüphanenin kimlerin kullandığını temel alarak farklı davranması gerekiyorsa, kütüphane kullanıcısının kütüphanenin davranışını değiştirmek için ayarlayabileceği geri arama işlevleri gibi teknikleri kullanın.

Answer 4

Bir pakete paylaşılan kod eklemek için çok iyi bir neden olması gerekir görüyoruz. Paylaşılan birkaç dosya varsa hepsini Paylaşılan adında bir dizine yapıştırın. Bu, dosyaların projeler arasında paylaşıldığını açıkça ortaya koymalıdır.

Ayrıca, otomatik yapıları yapmak için iyi bir derleme aracı kullanın, böylece bir şeyi kırmanız halinde yeterince erken öğreneceksiniz.

.bpl dosyaları, bileşenler için iyidir, ancak büyük miktarda paylaşılan dosya olmadıkça, bunun gibi şeyler için ciddi ek karmaşıklık getirir.

Answer 5

Sadece aynı fiziksel makinede çalışması ve bazı kodları paylaşması gereken iki ikiliyse, çalışma zamanı paketlerini kullanacağım. Çalışma zamanı paketlerinin çoğunlukla ya hep ya hiç olmayan bir yaklaşım olduğunu unutmayın. Bunları kullanmaya karar verdikten sonra artık RTL ve VCL ünitelerini doğrudan projelerinize bağlayamayacaksınız ve bunun yerine bunları ayrıca dağıtmak zorunda kalacaksınız. Ancak, tam olarak ne yaptığımı gösteren proje grupları ile birleştirildiğinde, paketler yine de sorununuz için iyi bir çözüm olabilir. Birden fazla projede bulunan ortak birimlerden nefret ediyorum. Paylaşılan birimleri bir pakette (ancak gerçek projelerinizi çalışma zamanı paketleri ile derlememekle) dahil etmek, bu paketi proje grubunuza eklemenizi sağlar, böylece siz (ve IDE!) Her zaman onlara kolayca erişebilir ancak projeye özel olarak güzel bir şekilde ayrılabilir. kodu. Kesinlikle, bu paketleri derlemek bile zorunda değilsin. Proje yöneticisinde sadece bir organizasyon birimi olarak hizmet edebilirler. Dosyalarda Bul için, ayrıca _package_ hiç bağlantılı olmayacaktır