Mi sono davvero interessato al framework dell'applicazione JBoss Seam. Poiché la nozione di iniezione/espulsione e stretta integrazione tra JSF/EJB/JPA è relativamente scarsa tra i framework di applicazioni Java, cercavo delle buone risorse per i modelli di progettazione e le best practice per l'utilizzo di questo framework. Ho parlato degli esempi e di diversi libri sull'argomento. Tuttavia, sono più interessato a modelli di progettazione reali che si confrontino con i tradizionali schemi di progettazione J2EE. Ad esempio, i DAO tradizionali rispetto a EntityHome/EntityQuery. Dove dovrebbe essere eseguita la logica aziendale? In classi di azione? O in classi di servizio dedicate? Apprezzerei molto ogni idea che gli sviluppatori Seam possano dare. Grazie!JBoss Seam Design Patterns?
risposta
Esistono molti schemi utili che è possibile utilizzare.
approccio tradizionale
view >> controller >> service >> domain
che può essere tradotto Per
/**
* view
*/
<h:commandButton value="Deposit" action="#{accountController.removeAccount(account)}"/>
/**
* controller
*/
@Name("accountController")
public class AccountController implements Serializable {
/**
* Usually a plain POJO or EJB
*/
private @In AccountService accountService;
public void removeAccount(Account account) {
accountService.removeAccount(account);
}
}
/**
* service
*/
@Name("accountService")
public class AccountServiceImpl implements AccountService {
private @In EntityManager entityManager;
public void removeAccount(Account account) {
entityManager.remove(account);
}
}
Se si dispone di alcune azioni che ha bisogno di manipolare i componenti JSF sul lato server, utilizzare un controller come mostrato sopra può essere una buona idea
Puoi anche usare
view >> service >> domain
Si è fondamentalmente lo stesso approccio mostrato sopra ma senza regolatore
o utilizzando incorporato nel modello mediatore utilizzando EntityHome/EntityQuery
view >> domain
Registra il tuo EntityHome come segue /WEB -INF/components.xml
<framework:entity-home name="accountHome" entity-class="br.com.ar.seam.Account"/>
Ora è possibile creare un alias utilizzando l'elemento fabbrica
<factory name="account" value="#{accountHome.instance}"/>
/**
* view
*
* Notice account will be evaluated as accountHome.instance
*/
<h:commandButton value="Deposit" action="#{account.remove}"/>
Nient'altro. Tenete a mente quando si utilizza EntityHome (JPA) o HibernateEntityHome (Sospensione) di solito è necessario sovrascrivere alcuni metodi per migliorare le prestazioni come segue
@Name("accountHome")
public class AccountHome extends EntityHome<Account> {
/**
* Override any method you want right here
*/
}
Chi logica di business ??? Puoi metterlo all'interno del tuo livello di servizio o puoi utilizzare un approccio basato sul dominio. Vedere here che si adatta meglio a ciò che si desidera
Test: utilizzare i componenti di prova di Seam in bundle. Date un'occhiata a Seam esempi directory Per ottenere una panoramica su come eseguire il test senza distribuzione
Se possibile, utilizzare seam-gen per generare il progetto. Seam in Action book, capitolo 2, può dare una buona idea su come avviare le funzionalità di seam-gen. leggi attentamente.Qualsiasi seam-gen generato progetto può essere aperto e testato in NetBeans ed Eclipse
componenti JSF: Date un'occhiata a here
C'è di più: non utilizzare più @ Out-jection. Usa invece @Factory. @ Out-jection sarà deprecato a favore del metodo @Factory.
Penso query è meglio memorizzati all'interno di un file esterno, perché
- È leggibile
- E 'gestibile
Come segue
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<query name="GIFT_CARDS_WITH_BUYER">
<![CDATA[
from
GiftCard c
left join fetch
c.buyer
where
c.recipientNotificationRequested = 1
]]>
</query>
<query name="GIFT_CARDS_WITHOUT_NO_RELATIONSHIP">
<![CDATA[
from
GiftCard
]]>
</query>
</hibernate-mapping>
Nice one, don' t
Un'altra risorsa va qui (formato pdf)
- 1. Design Patterns
- 2. Esercitazioni di JBoss Seam
- 3. Design Patterns Tutorial video
- 4. Vaadin: Design patterns
- 5. Design Patterns e Scala
- 6. Design Patterns - Strategy Pattern
- 7. rimaneggiamento dell'attività: Software Design Patterns
- 8. Design Patterns Used in CakePHP
- 9. Design Patterns for Delphi 2009
- 10. Chiamate API multiple: Design Patterns
- 11. Design Patterns of Resposibility Vs Decorator
- 12. Design Patterns Recommendation for Filtering Option
- 13. modifica anotations da JBoss Seam a CDI (JEE6)
- 14. Design Patterns for a Rails 3.2 JS-heavy App
- 15. Patterns JavaScript design aiuto necessario: Aumento allentato dei moduli
- 16. Chiunque ha funzionato con successo i test di integrazione con JBoss Embedded, Seam e Maven?
- 17. Ci sono degli svantaggi per SEAM?
- 18. Seam eccezioni centralizzate
- 19. Perché "Design Patterns" dice "due oggetti dello stesso tipo devono solo condividere parte delle loro interfacce"?
- 20. Come si chiama quando le persone cercano di abusare di Design Patterns?
- 21. Unusual Garbage Collection Patterns
- 22. Grunt Globbing patterns
- 23. Swift Patterns opzionali
- 24. C#: Enum anti-patterns
- 25. Hystrix Execution Patterns
- 26. Type Inference in Patterns
- 27. Tesseract user-patterns
- 28. Transazioni manuali con Seam POJO
- 29. java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator Seam weblogic 10.3
- 30. Quantifiers and patterns (formula QBF)
Wow! Ora questa è una risposta dettagliata. Grazie mille per l'intuizione! – Shadowman
Giusto, Arthur è il ragazzo Seam qui :) – BalusC
Bella risposta. Ma starei alla larga da Seam Application Framework. (EntityHome, EntityQuery ecc.) –