L'approccio Play framework porta necessariamente a confondere il codice?

Non deve portare a codice confuso, ma ci sono dei compromessi. A volte potresti scoprire che il tuo ORM sta estraendo tutti i campi di dati da una riga quando ne hai solo bisogno due, a volte le query non sarebbero le stesse di quelle che useresti o potresti aver bisogno di ottenere una maggiore profondità di entità rispetto all'ORM effettuerà automaticamente una query in modo che alla fine torni al database un paio di volte quando forse potresti teoricamente avere tutte queste informazioni in un solo viaggio.

Questi tipi di cose sono risultati standard dell'uso di un sistema ORM e non sono legati specificamente a una piattaforma specifica.

La domanda che devi porsi riguarda davvero quell'equilibrio e di conseguenza quello che ritieni sia importante:

• Vuoi scrivere codice molto dettagliato o ottenere codice scritto rapidamente?
• Vuoi risparmiare tempo sul processore o vuoi risparmiare tempo?
• Sarebbe preferibile utilizzare un server più potente o impiegare più tempo a scrivere codice più lungo?

Quando si tratta di MVC rispetto a MV-VM-C, che di nuovo si riduce alla scelta personale - nelle impostazioni MVC ho visto la logica in modelli che probabilmente non vi appartenevano teoricamente, nei casi in cui vengono utilizzati ViewModels, Ho visto classi vuote completamente ridondanti essere create solo per garantire che ogni modello avesse un ViewModel corrispondente anche quando nessuno dei due aveva una logica percepibile al loro interno.

La cosa importante è che prima di scegliere una piattaforma, leggi i suoi vantaggi e svantaggi e quando fai la tua scelta, impari ad usarla in un modo che significa che puoi scrivere un codice che si adatta con l'ethos del piattaforma e che tu (e altri sviluppatori) potrai leggere in futuro. Onestamente questo è più importante del fatto che la piattaforma che stai usando sia l'implementazione ideale di un modello di design specifico o di una svolta attuale. Voglio dire, conosco persone che scrivono buon codice in PHP - a volte è importante guardare l'immagine più grande. E non dimentichiamo che gli stessi schemi di design sono più come linee guida che regole attuali.

I tuoi dubbi sono validi.

Il pattern di default dei framework Rails è ottimo per i piccoli (er) programmi codificati da programmatori meno esperti che non hanno una conoscenza dell'architettura software - il framework fornisce uno scheletro per l'intera applicazione, tutte le astrazioni sono definite, dopo aver codificato 3 classi abbiamo qualcosa sullo schermo. Questo caso d'uso è utile anche per la prototipazione.

Non significa che un framework di questo tipo non possa essere usato quando si fa uno sviluppo software più serio - può (e probabilmente dovrebbe), ma più come uno strumento che come struttura principale del programma.

Disaccoppiare gli oggetti aziendali dalla vista è certamente una buona abitudine. Sono sicuro che può essere fatto con la stessa facilità quando si usa Play framework così come lo è con Spring. Puoi dare un'occhiata a Keynote di Robert Martin a Ruby Midwest 2011 , dove presenta un'architettura che disaccoppia completamente la logica di business dal quadro (o "meccanismo di consegna", come lo chiama). Usa Rails come esempio.