Java web uygulaması klasör yapısı

J2EE'ye yeni başlayan biri olarak, son zamanlarda J2EE Core: Servlets & Jsps'i kullanarak kendi projemi sıfırdan geliştirmeye başladım.

Proje klasörü yapımın doğru olup olmadığını değerlendiremedim. İşte benim proje klasör yapım.

Soru sormadan önce, birilerinin bana sorarsa neden bu tür klasör yapısını cevaplayamadığımı ya da haklı çıkaramayacağımı itiraf ediyorum. Soru: Jsps'imi web-inf dışına koymak iyi bir işaret mi? Değilse, neden böyle? Evet ise neden?

Bir J2EE web uygulaması için herhangi bir standart klasör yapısı sözleşmesi var mı, maven bazı standartlar getirdi biliyorum ama yine de, biz inanıyorum şartının gibi özelleştirebilirsiniz.

Ben googling biraz yaptık ve iki referans bulundu 1 2

buradaki cevaplar aynı sayfada değil, hangi sonuca varamadım.

Bir J2EE web uygulaması için klasör yapısını düzenlerken dikkat edilmesi gereken noktalar nelerdir, en önemlisi Jsps, statik içerik nereye gitmeli ve neden?

WAR dosyası için standart yapı:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

Maven bunu sizin için src / main / java, kaynaklar, webapp ve maven-webapp-eklentisindeki bağımlılıklarınızı (/ lib içine yerleştirerek) kullanarak üretir , ama bu uygulama. Dikkat edilmesi gereken önemli nokta, WEB-INF'ye koyduğunuz herhangi bir şeyin harici olarak erişilebilir olmaması , ancak WAR'ın kök dizinindeki her şeyin halka açık olmasıdır.

Genellikle uygulamanızın web.xml dosyasında tanımladığınız sunucu uygulamaları ve filtreleri kullanarak tüm erişimi işlemesini istediğiniz için kök dizinine fazla bir şey koymak istemezsiniz. Kökte bir sunucu uygulamasına, örneğin bir Struts eylemine yönlendiren bir index.html (veya .jsp) görmek yaygındır .

Stripes veya Struts gibi tipik MVC uygulamaları, kullanıcının JSP'lere doğrudan erişmesini önleyerek JSP'lerin yalnızca görüntülenebilir olmasını tercih eder. İsteği işledikten sonra JSP'lere yönlendiren denetleyiciler oluşturmayı önerirler ve JSP'ler yalnızca sonucu verir. Örneğin, form göndermek /loginiçin oturum açma isteğini işleyen, kullanıcının oturumunu oluşturan ve kullanıcıyı JSP ana sayfasının oturum açmış görünümüne yönlendiren bir eylem çalıştırılır.

"Doğru yol nedir?" veya "bu doğru yol mu?" ... bağlıdır .

Yapabileceğim tek şey size belirli fikirlere artılarını ve eksilerini anlatmak. Takip eden şey% 100. Herhangi bir özel gereksinim veya kural bilmiyorum. Eminim birisi bana katılmayacaktır.

JSP en

JSP'leri WEB-INF'ye yerleştirip yerleştirmemeye çalışalım.

JSP'leri WEB-INF'ye koymanın artıları:

• JSP'lerin nasıl yürütüldüğünü siz denetlersiniz. Bir JSP'nin parametrelenmesini ve yeniden kullanılabilir olmasını istiyorsanız (yine de bir JSP ile gerçekten zor), bunları WEB-INF'ye yerleştirebilir ve ön işleme yapmak için bir sunucu uygulaması veya Struts eylem denetleyicisi veya başka bir ön denetleyici kullanabilirsiniz. ve ardından denetimi doğru ortam bağlamında geçirerek JSP'ye iletin (istek öznitelikleri, güvenlik denetimleri, parametre sanitasyonu vb. gibi)
• Bir güvenlik duvarı veya IDS düzeyinde, bir kullanıcının web köküne JSP yükleme ve ardından web sunucusu olarak kod yürütme olasılığını azaltmak için HTTP isteklerini * .jsp'ye engelleyebilirsiniz. Mevcut bir JSP'yi aşırı yazmak zorunda kalacaklardı. Büyük bir güvenlik kazancı değil, ama uzlaşmayı biraz daha zorlaştırıyor.
• MVC, ön kontrolör, sunucu uygulaması filtreleri, bağımlılık enjeksiyonu vb. Gibi iyi alışkanlıkları, tüm işi yapan ve okunması / bakımı zor olan büyük bir canavar JSP'nin aksine uygular.

JSP'leri WEB-INF'ye koymanın eksileri:

• Açık işlem gerektirmeyen basit bir bağımsız sayfa olsa bile sayfaya doğrudan erişemezsiniz. Bunun nedeni, / WEB-INF altındaki dosyalara sunucu uygulaması kapsayıcısı tarafından erişilememesidir.

Statik dosyalar

HTML, resim, stil sayfası, javascript vb.Gibi tamamen statik dosyalar açısından bunları web kökünün altına koyun (sizin durumunuzda my_app), ancak NOT / WEB-INF (erişilebilir olmadığı için).

Genel düzen

Genel dizin düzenine gelince, bu biraz oluşturma işleminize bağlıdır. Ben her şeyi "src" veya "kaynak" altında saklamak gibi çünkü bina tarafından hangi dosyaları oluşturulan ve hangi saf kaynak dosyaları olduğunu netleştirir. mainjunit sınıfları gibi test kodlarını ana kaynak kodunuzdan ayırmanıza izin verir, bu da iyidir. Ama eğer birim testleriniz yoksa (oh hayır!), O zaman anlamsız bir ayrımdır.

Öte yandan, oluşturma sırasında web kökünü hiç değiştirmezseniz (tüm JSP ve statik dosyalar gibi), belki de dosyaları en üst düzeyde tutarsınız ve dosyaları gerektiği gibi kopyalar /webrootveya /deploykopyalarsınız. .class veya .jar dosyaları. İnsanların (özellikle geliştiricilerin) aşırı örgütlenme alışkanlığıdır. Aşırı düzenlemenin iyi bir işareti, yalnızca tek bir alt klasör içeren çok sayıda klasöre sahip olmaktır.

Gösterdikleriniz

Maven tarafından belirlenen bir kuralı izlediğinizi belirttiniz, bu yüzden zaten maven kullanıyorsanız, bu düzene sadık kalın. Açıkladığınız düzende kesinlikle yanlış bir şey yok.

Peki, src / main / webapp bana bir maven projesini hatırlatıyor. Hangisi iyi.

My_app / jsps için emin değilim. Geliştiriciler genellikle jsp'lerini webapp klasöründe veya biraz url eşlemesi yapmak istiyorsanız, bir webapp / jsp dizininde bırakırlar.

!Uyarı! : Asla web-inf içine bir jsp dosyası koymamalısınız. WEB-INF web sitenizi yapılandırmak için yalnızca xml dosyaları içermelidir. Unutmayın, jsp'niz bir web sayfası veya bir web sayfasının parçasıdır.

Şablon, kısmi ... gibi klasör adlarını kullanabilirsiniz. Bir yabancıyı bulmak kolay olmalı. Tam sayfalar, şablonlar, kısmi görünümler gibi farklı içerik türlerini ayırın ...

Ben Brice katılıyorum . Ben de J2EE'ye yeni başlıyorum, ama başlangıçta kolay ve net bir şekilde çalışmanın daha iyi olduğunu düşünüyorum.

Kök klasör WEBAPP'dir ve web yapınızı sayfaların çoğunun orada bulunacağını düşünerek yapmalısınız. Değilse, sayfalar aralarında iletişim kurduğunda muhtemelen dosya ilişkilerini hatasız yönetemezsiniz.

Aslında WAR uygulaması olmadan inşa edilebilir WEB-INF/web.xml. İçeride sadece Java sınıflarıyla WAR uygulaması yapmak mümkündür.

Kaynak: Bir web.xml Dağıtım Tanımlayıcı Öğeleri

Java EE ek açıklamalarıyla standart web.xml dağıtım tanımlayıcısı isteğe bağlıdır. De sunucu uygulaması 3.0 patent açıklamasına göre http://jcp.org/en/jsr/detail?id=315 ek açıklamalar bu servlet, filtreler, dinleyici, ve etiket işleyicileri gibi bazı Web bileşenleri hakkında tanımlanabilir.

Bu nedenle, günümüzde WAR oluşturmak, .waruzantılara sahip JAR'a benzemek mümkün :)

Sorunuzu cevaplayan WAR yapısı gereksinimlerinize bağlıdır.

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)