JSF destek fasulye yapısı (en iyi uygulamalar)


118

Umarım bu yazıda, JSF sayfaları ve destekleyici fasulye arasındaki arayüz için en iyi uygulamalar hakkında insanların görüşlerini alabilirim.

Asla çözemeyeceğim bir şey, destek fasulyelerimin yapısı. Üstelik konuyla ilgili hiç iyi bir makale bulamadım.

Hangi destek fasulyelerine hangi özellikler aittir? Yeni bir çekirdek oluşturmak ve üzerine özellikleri eklemek yerine, belirli bir çekirdeğe daha fazla özellik eklemek ne zaman uygundur? Basit uygulamalar için, bir fasulyeyi diğerine enjekte etmenin karmaşıklığı göz önünde bulundurulduğunda, tüm sayfa için sadece tek bir destek fasulyesine sahip olmak mantıklı mı? Destek fasulyesi herhangi bir gerçek iş mantığı içermeli mi yoksa kesinlikle veri içermeli mi?

Bu ve ortaya çıkabilecek diğer soruları yanıtlamaktan çekinmeyin.


JSF sayfası ile destek fasulyesi arasındaki bağlantıyı azaltmaya gelince, JSF sayfasının herhangi bir destek fasulyesi mülkünün özelliklerine erişmesine asla izin vermem. Örneğin, aşağıdaki gibi bir şeye asla izin vermem:

<h:outputText value="#{myBean.anObject.anObjectProperty}" />

Her zaman şöyle bir şeye ihtiyacım var:

<h:outputText value="#{myBean.theObjectProperty}" />

destek fasulyesi değeri:

public String getTheObjectProperty()
{
    return anObject.getAnObjectProperty();
}

Bir koleksiyon üzerinde döngü oluşturduğumda, örneğin bir veri tablosundaki bir nesnenin ayrıntılarına inmekten kaçınmak için bir sarmalayıcı sınıfı kullanıyorum.

Genel olarak, bu yaklaşım bana "doğru" geliyor. Görünüm ve veriler arasında herhangi bir bağlantı olmasını önler. Yanılıyorsam lütfen beni düzeltin.


Bir örnek verebilir misiniz: Bir koleksiyon üzerinde döngü yaptığımda, örneğin bir veri tablosundaki bir nesnenin ayrıntılarına inmekten kaçınmak için bir sarmalayıcı sınıfı kullanırım.
Koray Tugay

2
Daha fazla bilgi için, stackoverflow.com/questions/7223055/…
Zack

Yanıtlar:


146

Bunu kontrol etmek isteyebilirsiniz: JSF tarafından yönetilen farklı çekirdek türleri arasında ayrım yapmak .

Neil Griffin tarafından yukarıdaki makalede tanımlandığı gibi, farklı fasulye türlerinin bir açıklaması:

  • Model Yönetilen-Bean : Normalde oturum kapsamı. Bu tür yönetilen fasulye, MVC tasarım modelinin "Model" endişesine katılır. "Model" kelimesini gördüğünüzde - DATA'yı düşünün. JSF model fasulyesi, özellikleri kapsayan alıcılar / ayarlayıcılar ile JavaBean tasarım modelini izleyen bir POJO olmalıdır. Bir model çekirdeği için en yaygın kullanım durumu, bir veritabanı varlığı olmak veya basitçe bir veritabanı sorgusunun sonuç kümesinden bir satır kümesini temsil etmektir.
  • Backing Managed-Bean : Normalde kapsam isteyin. Bu tür yönetilen fasulye, MVC tasarım modelinin "Görünüm" endişesine katılır. Destek çekirdeğinin amacı, kullanıcı arabirimi mantığını desteklemektir ve bir JSF görünümü veya bir Facelet kompozisyonunda bir JSF formu ile 1 :: 1 ilişkisine sahiptir. Genellikle ilişkili alıcılar / ayarlayıcılarla JavaBean tarzı özelliklere sahip olsa da bunlar, temel alınan uygulama veri modelinin değil, Görünümün özellikleridir. JSF destek fasulye ayrıca JSF actionListener ve valueChangeListener yöntemlerine sahip olabilir.
  • Controller Managed-Bean : Normalde kapsam isteyin. Bu tür yönetilen fasulye, MVC tasarım modelinin "Kontrolör" endişesine katılır. Bir denetleyici çekirdeğinin amacı, bir tür iş mantığı yürütmek ve JSF gezinme işleyicisine bir gezinme sonucunu döndürmektir. JSF denetleyici-fasulyeleri genellikle JSF eylem yöntemlerine sahiptir (actionListener yöntemlerine sahip değildir).
  • Support Managed-Bean : Normalde oturum veya uygulama kapsamı. Bu tür fasulye, MVC tasarım modelinin "Görünüm" endişesinde bir veya daha fazla görünümü "destekler". Tipik kullanım örneği, birden fazla JSF görünümünde görünen JSF h: selectOneMenu açılır listelerine bir ArrayList sağlamaktır. Açılır listelerdeki veriler kullanıcıya özelse, çekirdek oturum kapsamında tutulacaktır. Bununla birlikte, veriler tüm kullanıcılar için geçerliyse (illerin açılır listeleri gibi), o zaman çekirdek tüm kullanıcılar için önbelleğe alınabilmesi için uygulama kapsamında tutulacaktır.
  • Utility Managed-Bean : Normalde uygulama kapsamı. Bu tür fasulye, bir veya daha fazla JSF görünümüne bir tür "yardımcı program" işlevi sağlar. Buna iyi bir örnek, birden çok web uygulamasında yeniden kullanılabilen bir FileUpload çekirdeği olabilir.

8
Bu harika bir makale. Daha önce hiç görmedim ve gönderdiğinize kesinlikle sevindim. Bunu reddeden kişi çılgın. IceFaces'e özgü değil.
Zack Marrapese

2
Asıl makalenin bağlantısı gitmiş görünüyor.
Bill Rosmus

Bir kopyası burada
ChrLipp

10
Yine de, bu cevabın şu anda 71 olumlu oyda olduğunu anlayamıyorum. JSF uygulamalarını bu kurallara göre uygulayanlar, şüphesiz daha sonra JSF'nin korkunç derecede opak bir çerçeve olduğundan ve JSF uygulamalarının büyük bir kod karmaşası olduğundan bahsediyor olmalı ve hepsi yanlış derslere ve sözde sözlere dayanan kendi kötü yaklaşımları yerine JSF'yi suçluyor olmalıdır. "en iyi uygulamalar" öğrenildi.
BalusC

bu fasulye mantığından herhangi biri sunucu yerine tarayıcıda mı yürütülüyor?
eskalera

14

Harika soru. JSF'ye geçtiğimde aynı ikilemle çok acı çektim. Bu gerçekten uygulamanıza bağlıdır. Ben Java EE dünyasındanım, bu nedenle destekleyici çekirdeklerinizde mümkün olduğunca az iş mantığı olmasını tavsiye ederim. Mantık tamamen sayfanızın sunumuyla ilgiliyse, arka planda olması sorun değil.

JSF'nin (birçok) güçlü yönlerinden birinin aslında etki alanı nesnelerini doğrudan yönetilen fasulye üzerinde gösterebilmeniz olduğuna inanıyorum. Bu nedenle <:outputText value="#{myBean.anObject.anObjectProperty}" />yaklaşımı şiddetle tavsiye ederim , aksi takdirde her bir mülkü manuel olarak teşhir ederek kendiniz için çok fazla iş çıkarırsınız. Ayrıca, tüm özellikleri kapsüllediyseniz, veri eklerken veya güncellerken biraz karışıklık olur. Tek bir etki alanı nesnesinin yeterli olmayabileceği durumlar vardır. Bu durumlarda, onu çekirdek üzerinde göstermeden önce bir ValueObject hazırlarım .

DÜZENLEME: Aslında, ortaya çıkarmak istediğiniz her nesne özelliğini kapsülleyecekseniz, bunun yerine UI bileşenlerini destek çekirdeğine bağlamanızı ve ardından içeriği doğrudan bileşenin değerine enjekte etmenizi tavsiye ederim.

Fasulye yapısı açısından benim için dönüm noktası, web uygulamaları oluşturma hakkında bildiğim her şeyi zorla görmezden geldiğim ve onu bir GUI uygulaması olarak görmeye başladığım zamandı. JSF, Swing'i çok taklit eder ve bu nedenle, Swing uygulamaları geliştirmek için en iyi uygulamalar çoğunlukla JSF uygulamaları oluşturmak için de geçerlidir.


Anlayışınız için teşekkürler. Swing uygulamaları konusunda hiçbir zaman pek bir şey yapmadım (uzun zaman önce akademik projeler dışında). Salınım uygulamalarının bazı iyi prensipleri nelerdir? Ayrıca, değerleri eklerken ve güncellerken neden karışıklık oluyor? bana aynı görünüyor?
Zack Marrapese

5

Bence destek fasulyelerinizle ilgili en önemli şey, mantıklarını ayırmaktır. Bir CMS sistemi için bir ön sayfanız varsa, her kod parçasını tek bir çekirdeğe koymanın kötü bir uygulama olduğunu düşünürdüm çünkü:

  1. Fasulye eninde sonunda çok büyüyecekti
  2. Diğer kişilerin, giriş sayfasında sorun gideriyorlarsa aradıkları şeyi bulmaları daha kolaydır, eğer daha sonra kolayca loginBean.java dosyasına bakabilirlerse.
  3. Bazen, kodunuzun geri kalanından açıkça farklı olan küçük işlevsellik parçalarına sahip olursunuz, bunu ayırarak, bu kodu daha büyük bir şeye yeniden geliştirmeyi / genişletmeyi, zaten iyi olan güzel bir çekirdeğe sahip olduğunuzda, kendi için daha kolay hale getireceğinizi hayal ediyorum. yapısı.
  4. 1 büyük fasulyeye sahip olmak, hepsini yapmak için, bu MyBigBean gibi bildirimler yapmanız gerektiğinde / yapmanız gerektiğinde onu daha fazla belleğe bağımlı hale getirecektir bigBean = new MyBigBean (); funksjonality kullanmak yerine aslında LoginBean loginBean = new LoginBean () yaparak ihtiyaç duyduğunuz; (Burada yanılıyorsam düzelt ???)
  5. Bence fasulyenizi ayırmak, yöntemlerinizi ayırmak gibidir. 100'den fazla satırı çalıştıran 1 büyük yöntem istemiyorsunuz, bunun yerine onu kendi özel görevlerini yerine getiren yeni yöntemlerle bölmek istiyorsunuz.
  6. Unutmayın, büyük olasılıkla sizden başka birinin de JSF projeleriniz üzerinde çalışması gerekecek.


Bağlantıya gelince, JSF sayfalarınızın backingbean'daki nesnelerdeki özelliklere de erişmesine izin vermeyi zahmetli bir sorun olarak görmüyorum. Bu, JSF'de yerleşik olan destektir ve gerçekten sadece imo okumayı ve oluşturmayı kolaylaştırır. MVC mantığını şimdiden kesinlikle ayırıyorsun. Bunu yaparak, arka fasulyenizde alıcılar ve ayarlayıcılarla tonlarca hattan tasarruf etmiş olursunuz. Örneğin, sunumumda bazı özellikleri kullanmam gereken web servisleri tarafından bana verilen çok büyük bir nesnem var. Her özellik için bir alıcı / ayarlayıcı yaparsam, fasulyem en az 100 değişken satırı ve özellikleri elde etmek için yöntemlerle genişlerdi. Yerleşik JSF işlevini kullanarak zamanımdan ve değerli kod satırlarından tasarruf edilir.

Soru zaten cevaplanmış olarak işaretlenmiş olsa bile, bununla ilgili sadece 2 sentim.


1
ancak, fasulyenizde oturan devasa bir nesneniz varsa ve - örneğin - JSF sayfasından bu nesneyi araştıran 15 EL işlevine sahipseniz, artık yalnızca fasulyeye değil, o nesneye de bağlısınız. Bu nedenle, kullanıcı arayüzünü bozmadan bu nesneyi kaldırmak zor olacaktır.
Zack Marrapese

1
Ama destek fasulyeniz o nesneye de bağlanmayacak mı? Ve kullanıcı arayüzünüz arka çekirdeğe mi bağlı? Daha sonra onu değiştirmeniz gerektiğinde, hem UI hem de bean'daki tüm alıcılarınızı / ayarlayıcılarınızı değiştirmeniz gerekecektir.
Chris Dale

4

Her sorunuza cevap vermeyebilirim, çünkü çok azı duruma göre oldukça bağımlı görünüyor.

  • Bu, destek fasulyenizde bir iş mantığına sahip olmak için iyidir. Nereden geldiğine bağlı. Alan odaklı tasarım uyguluyorsanız, iş mantığını destek fasulyesine dahil etmek isteyeceksiniz veya kalıcılık mantığı da olabilirsiniz. Neden bu kadar aptalca bir nesne olduğunu tartışıyorlar. Nesne sadece durumu değil, davranışı da taşımalıdır. Öte yandan, işleri yapmanın geleneksel Java EE yöntemini düşünürseniz, destek fasulyenizde veri varmış gibi hissedebilirsiniz, bu aynı zamanda sizin varlık fasulyeniz olabilir ve bazı oturum fasulyesinde veya başka bir şeyde diğer iş ve kalıcılık mantığı olabilir. Bu da iyi.

  • Sayfanın tamamı için tek arka çekirdeğe sahip olmak son derece iyi. Yalnız bununla ilgili bir sorun görmüyorum. Bu doğru görünmeyebilir, ancak duruma göre değişir.

  • Diğer sorunuz, elinizde olan duruma çok daha fazla bağlıdır. Buraya etki alanı yönlendirmeyi tercih ederim, mevcut olana mülk eklemek veya bunun için yeni bir fasulye oluşturmak uygun olabilir. Hangisi daha iyi uyuyor. Bunun için sihirli bir değnek olduğunu sanmıyorum.

  • Hangi özelliklerin hangi destek fasulyesine ait olduğu. Peki, etki alanı nesnesine bağlı değil mi? Veya soru o kadar net değil olabilir.

Üstelik verdiğiniz kod örneğinizde çok büyük bir fayda görmüyorum.


Örneğin, JDBC sorguları ile oluşturulan evde hazırlanmış POJO'ları kullanmaktan, biraz farklı alan adlarına sahip Hibernate varlıklarına geçecek olsaydık, yalnızca destek fasulyesini değiştirmek zorunda kalmazdık. JSF sayfasını da değiştirmemiz gerekir. Kod örneğimde öyle değil. Sadece fasulyeyi değiştir.
Zack Marrapese

Bu durumda destek fasulyelerinizi, varlıklarınızı yapabilirsiniz. o zaman sadece JSF sayfalarını değiştirmeniz gerekir. Ya da neden mülklerin adını değiştirdiğinize bağlıdır? bu yalnızca alanı veritabanı sütun adınızla eşleşecek şekilde yeniden adlandırdığınızda anlamlıdır. Ama bu tamamen farklı bir durum.
Adeel Ansari

4

Her sayfada sadece bir destek fasulyesi bulundurmam gerekmez. İşlevselliğe bağlıdır, ancak çoğu zaman bir sayfa tek bir işlevi işlediğinden, sayfa başına bir çekirdek vardı. Örneğin bir sayfada bir kayıt bağlantım (RegisterBean ile bağlantı kuracağım) ve bir alışveriş sepeti bağlantım (ShoopingBasketBean) var.

Bu <: outputText value = "# {myBean.anObject.anObjectProperty}" /> çekirdeklerini normalde veri nesnesini tutan işlem çekirdekleri olarak desteklediğim için kullanıyorum. Veri nesnelerimin özelliklerine erişmek için destek çekirdeğime bir sarmalayıcı yazmak istemiyorum.


0

İşletme kodunu View's olmadan test etmeyi seviyorum, bu yüzden BackingBeans'i Görünümden Model koduna arayüzler olarak görüyorum. Bir BackingBean'e asla herhangi bir kural veya süreç koymam. Bu kod, Hizmetlere veya Yardımcılara girerek yeniden kullanıma izin verir.

Doğrulayıcılar kullanıyorsanız, onları BackingBean'inizden çıkarın ve doğrulama yönteminizden onlara referans verin.

Seçimleri, Telsizleri, Onay Kutularını doldurmak için DAO'lara erişirseniz, bunu her zaman bir BackingBean'dan yapın.

İnan bana!. Bir JavaBean'ı bir BackingBean'e enjekte edebilirsiniz, ancak bir BackingBean'i başka birine enjekte etmeyi deneyebilirsiniz. Yakında bir bakım ve kod anlayışına sahip olacaksınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.