Come evitare la duplicazione del modello nelle applicazioni web JavaEE con un front-end JSON

Question

Come evitare la duplicazione del modello nelle applicazioni web JavaEE con un front-end JSON

#1 da (1 voti)

2

Recentemente abbiamo sviluppato un'app Web che utilizza il seguente stack tecnologico:

ibernazione come orm
molla
extjs (MVC javascript front end)

Per 1 oggetto business, lascia che sia un personale, abbiamo:

1) una classe del personale (ibernato) 2) PersonnelDTO (spiegherà perché ne avevamo bisogno) 3) un modello javascript Personnel per Extjs (non so potrebbe essere altri framework di interfacce utente javascript non ha bisogno di un modello definito)

La necessità del numero 2 è nata quando non siamo riusciti a gestire gli oggetti di ibernazione avanti e indietro, occupandoci di sessioni e riferimenti circolari ecc.

Inoltre, in alcuni casi è necessario un oggetto Personale completo (campi completi uniti), a volte solo pochi campi e una relazione. A volte hai bisogno di tutte le informazioni per elaborare un Personale ma non puoi inviarlo fino al cliente (sicurezza, motivi di privacy). Quindi abbiamo utilizzato DTO per disaccoppiare oggetti e oggetti del modello che verranno inviati attraverso il filo.

Aggiungere-rimuovere un campo in un progetto di questo tipo diventa molto noioso e soggetto a errori. L'aggiunta di un campo richiede:

aggiungi alle tabelle DB
aggiungi all'oggetto modello
aggiungi a DTO
aggiungi al modello - > Convertitore DTO (quando si tratta di un campo che non può essere mappato automaticamente) in relazione a diversi scenari che richiedono diverse quantità di informazioni sul modello
aggiungi al modello Extjs
aggiungi ai moduli CRUD nella pagina
aggiungi a client e server validatori ...

Non esiste un approccio migliore alla creazione di applicazioni simili? Stiamo pensando di iniziare un nuovo progetto e non vogliamo commettere gli stessi errori.

rest mvc java-ee extjs

posta Reek 06.09.2014 - 22:34

fonte

1 risposta

Leggi altre domande sui tag rest mvc java-ee extjs

Quale modello di progettazione per una singola classe che accede a un oggetto che rappresenta una struttura dati? Come scrivo il mio BLL per renderlo riutilizzabile?

score 1 · Answer 1

Isn't there a better approach to building similar applications?

Sto lavorando a un progetto di medie dimensioni (150k LoC), con una configurazione simile:

Spring 4
OpenJPA per la persistenza
jQuery come unico "framework" front-end. Ho introdotto Backbone.JS che è adottato solo a metà. Una buona parte della nostra applicazione è grid over data , che viene implementata tramite datatables.net .

Stiamo affrontando problemi simili.

In generale, c'è solo poco o nessun aiuto per questo. Se stai usando ORM, devi usare @Entity -POJOs. Se non vuoi esporre questi oggetti all'esterno, non ci sono molte opzioni:

1) Come già fai: usa DTO s - ma c'è lo svantaggio di mappare i campi e mantenere i campi sincronizzati 2) Crea un'istanza di un nuovo Domainobject - come detto sopra: @Entities sono POJO e copia su quei campi che vuoi esporre.

Alcune delle nostre applicazioni sono grid over data , quindi non c'è sempre la necessità di oggetti di dominio completi ea volte è necessario un gruppo di attributi da diversi oggetti. Per tali casi c'è la possibilità di lavorare con Constructor expressions in the SELECT clause (vedi specifica ). Quindi potresti creare aggregate-objects (o comunque vuoi dare un nome a questi DTO s) che potrebbero estendersi su più tabelle e dove ogni attributo è associato a una colonna del tuo gruppo di risultati. In questo caso l'oggetto new non è necessariamente un @Entity . Deve fornire solo un costruttore che prende tutte le colonne. ( Nota a me stesso: prova questo per @Entities ).

add to model -> DTO converter (when it's a field that can't be automatically mapped) regarding different scenarios that requires different amount of information about model

Questo sarebbe meglio risolto tramite reflection : copia su tutti i campi nel nuovo oggetto dal vecchia. Fatto.

Quanto segue è molto soggettivo:

I find ORM isn't the perfect fit for our project. It is a nice to have which frees you from writing tedious boilerplate code, but comes with several downsides: performance trouble (objects involve multiple _LEFT JOIN_s, which you wouldn't need nor make, when writing SQL), too much overhead for simple queries (you get full objects restored instead of just 2 columns or so needed), problems with joins (you are only allowed to join tables, which reflect your models - otherwise, you have to use tricks to get around). If I would start over, I would take a mixed approach: ORM for simple stuff and doing complex stuff with JDBC-templates (our project is currently 100% ORM-Driven).

Detto questo, ora dobbiamo dare un'occhiata al frontend: Dall'avvento di MV * -frameworks sul lato client, sorge la domanda, dove mettere lo stress su: lato client vs lato server convalida o utilizzo di entrambi. Ecco un bel talk di yeahuda Katz su » il racconto dei due MVC « .

Se usi la strada lato client , non hai una duplicazione di "modelli", hai modelli lato client e "oggetti persistenza" ( @Entities )

Per riassumere:

alcuni punti critici rimangono: aggiungi alle tabelle DB, aggiungi all'oggetto modello, (aggiungi al DTO), aggiungi al modello Extjs
alcuni potrebbero essere resi più facili: aggiungi al modello - > DTO converte (usa reflection)
potresti decidere su o-o-base per alcuni: aggiungere a client e server validatori

Le moderne applicazioni sono complesse.