Modelli MVC in Clojure

Question

In qualità di sviluppatore di Ruby on Rails, durante la progettazione/implementazione di un'applicazione Web, prendo concetti essenziali/entità dal dominio del problema e li implemento come modelli. Tipicamente, quelle sono classi derivate da una classe ORM di base (ad esempio ActiveRecord::Base), esse mappano i record da una tabella di database e aggiungono metodi aggiuntivi che implementano la logica di business relativa al modello.

Il vantaggio di questo approccio è che è possibile trovare rapidamente tutte le logiche di business relative all'oggetto dal dominio del problema, in modo che se la classe del modello non è grande, è possibile comprendere in modo efficiente come funziona quella parte dell'applicazione. Si è anche separato da tutte le logiche di presentazione. Inoltre, grazie a ORM i metodi di business logic contengono pochi codici specifici per DB e quindi abbastanza chiari e facili da leggere.

Lo svantaggio è che tali classi spesso raggiungono dimensioni enormi e quindi difficili da comprendere nel loro complesso.

Quindi le mie domande sono:

• Do Clojure ecosistema fornire alcune librerie che soddisfano una funzione simile a ORM di OOP?
• Qual è la "modalità Clojure" per organizzare tale codice?
• Quali sono i vantaggi e gli svantaggi dell'approccio?
• Alcuni articoli/libri/discorsi che spiegano e giustificano l'approccio?
• Esistono alcune applicazioni open source (esempio) che mostrano l'approccio?

Answer 1

Una delle filosofie trainante dello sviluppo di Clojure è quello separate complex things al massimo livello ragionevole, e trattare dati come dati e quindi di evitare la combinazione dei dati e separata value state and identity.

• L'ecosistema Clojure fornisce alcune librerie che svolgono una funzione simile agli ORM di OOP? Il desiderio di elaborare i dati con funzioni pure che trasformano una struttura dati in un'altra fa sì che alcuni programmatori clojure evitino gli ORM anche se c'è nessun motivo per cui non si può usare Hibernate in Clojure se lo si desidera veramente.

• Qual è la "modalità Clojure" per organizzare tale codice? Mi piace Amit Rathore's presentation of the topic

• Quali sono i vantaggi e gli svantaggi dell'approccio? Rich Hickey offre un'eccellente discussione su queste idee in questo
• Alcuni articoli/libri/discussioni che spiegano e giustificano l'approccio? Io personalmente raccomando Il Joy of Clojure,

Answer 2

Per dirla semplicemente, non si avvolgono roba in un oggetto, si programma direttamente con strutture di dati come liste, insiemi e mappe. Pertanto, il lavoro svolto con gli ORM è stato ridotto alla conversione di una struttura dati in un'altra: ad esempio una funzione user-row->user-record potrebbe convertire un elenco di valori che viene inserito da un database SQL in una mappa che rappresenta un utente nella logica di business dell'app. Quando salvi l'utente, devi chiamare una funzione inversa.

Devo dire che per un programmatore esperto di OOP è davvero difficile per "ottenere" il fatto che ci sono molte meno cerimonie in giro.Il nostro cervello sembra combattere questa idea - IMHO perché sembra troppo semplice e immaturo per un esperto sviluppatore/architetto di software. :-) Vorrei poter scrivere una risposta più complicata piena di termini strani per sembrare un vero esperto, ma in realtà non posso, perché non c'è molto altro da aggiungere. :-)

A proposito, un piccolo ma interessante punto: l'uso pervasivo delle strutture di dati è una pratica considerata errata nel mondo OOP. Ad esempio, non è necessario archiviare denaro in una semplice tupla [10, "USD"] ma piuttosto scrivere completo public class Money che incapsulerebbe tutte le valute, confrontando, arrotondando ecc. Ma scrivere tuple è esattamente ciò che facciamo in FP. Ricordo di avere alcuni strani sentimenti riguardo a ciò che proviene dal mondo OOP.

Quando si tratta di organizzare il codice più o meno le stesse regole di OOP si applicano in termini di spazi dei nomi. Organizzi il codice in base all'argomento come faresti con i pacchetti java, tranne per il fatto che tutte le funzioni (che hai usato per chiamare i metodi) sono ora senza stato e solitamente considerano argomenti come il record utente sopra menzionato. Quindi invece di foo.barChange() si dovrebbe avere (bar foo) dove la pura funzione bar restituirebbe una nuova struttura di dati foo2 invece di modificare lo stato di foo.

Detto questo uno dei vantaggi della programmazione orientata agli oggetti è che non solo non v'è stata molte applicazioni scritte utilizzando questo paradigma, ma ancora più importante v'è stata più generazioni di approcci sperimentati (questo è come siamo arrivati ​​a cose come popolarità di oggi dei contenitori DI ecc. ecc.). La programmazione funzionale non ha ancora questo. Fondamentalmente nessuno ha un comprovato manuale finale su come fare l'architettura di un'app in FP. E a proposito, questo è il motivo per cui le persone sono generalmente scoraggiate dallo scrivere grandi strutture e incoraggiate a stare con le funzioni di trasformazione dei dati. In questo modo puoi sempre collegarlo come vuoi ed evitare le insidie ​​architettoniche.