Un'implementazione tipica di un repository DDD non sembra molto OO, ad esempio un save()metodo:
package com.example.domain;
public class Product { /* public attributes for brevity */
public String name;
public Double price;
}
public interface ProductRepo {
void save(Product product);
}
Parte dell'infrastruttura:
package com.example.infrastructure;
// imports...
public class JdbcProductRepo implements ProductRepo {
private JdbcTemplate = ...
public void save(Product product) {
JdbcTemplate.update("INSERT INTO product (name, price) VALUES (?, ?)",
product.name, product.price);
}
}
Tale interfaccia prevede Productche sia un modello anemico, almeno con getter.
D'altra parte, OOP afferma che un Productoggetto dovrebbe sapere come salvarsi.
package com.example.domain;
public class Product {
private String name;
private Double price;
void save() {
// save the product
// ???
}
}
Il fatto è che quando Productsa come salvarsi, significa che il codice di infrastruttura non è separato dal codice di dominio.
Forse possiamo delegare il salvataggio a un altro oggetto:
package com.example.domain;
public class Product {
private String name;
private Double price;
void save(Storage storage) {
storage
.with("name", this.name)
.with("price", this.price)
.save();
}
}
public interface Storage {
Storage with(String name, Object value);
void save();
}
Parte dell'infrastruttura:
package com.example.infrastructure;
// imports...
public class JdbcProductRepo implements ProductRepo {
public void save(Product product) {
product.save(new JdbcStorage());
}
}
class JdbcStorage implements Storage {
private final JdbcTemplate = ...
private final Map<String, Object> attrs = new HashMap<>();
private final String tableName;
public JdbcStorage(String tableName) {
this.tableName = tableName;
}
public Storage with(String name, Object value) {
attrs.put(name, value);
}
public void save() {
JdbcTemplate.update("INSERT INTO " + tableName + " (name, price) VALUES (?, ?)",
attrs.get("name"), attrs.get("price"));
}
}
Qual è l'approccio migliore per raggiungere questo obiettivo? È possibile implementare un repository orientato agli oggetti?
6
OOP dice che un oggetto Prodotto dovrebbe sapere come salvarsi - Non sono sicuro che sia corretto davvero ... OOP in sé non lo impone davvero, è più un problema di progettazione / modello (che è dove DDD / qualunque-tu -use entra)
—
jleach
Ricorda che nel contesto di OOP, parla di oggetti. Solo oggetti, non persistenza dei dati. La tua dichiarazione indica che lo stato di un oggetto non deve essere gestito al di fuori di se stesso, con il quale sono d'accordo. Un repository è responsabile del caricamento / salvataggio da alcuni livelli di persistenza (che è al di fuori del regno di OOP). Le proprietà e i metodi della classe dovrebbero mantenere la propria integrità, sì, ma ciò non significa che un altro oggetto non possa essere responsabile della persistenza dello stato. Inoltre, getter e setter devono garantire l'integrità dei dati in entrata / in uscita dell'oggetto.
—
Giovedì
"questo non significa che un altro oggetto non possa essere responsabile della persistenza dello stato." - Non l'ho detto. L'importante è che un oggetto dovrebbe essere attivo . Significa che l'oggetto (e nessun altro) può delegare questa operazione a un altro oggetto, ma non viceversa: nessun oggetto dovrebbe semplicemente raccogliere informazioni da un oggetto passivo per elaborare la propria operazione egoistica (come farebbe un repository con i getter) . Ho cercato di implementare questo approccio nei frammenti sopra.
—
ttulka,
@jleach Hai ragione, la nostra comprensione di OOP è diversa, per me getter + setter non sono affatto OOP, altrimenti la mia domanda non aveva senso. Grazie lo stesso! :-)
—
ttulka,
Ecco un articolo sul mio punto: martinfowler.com/bliki/AnemicDomainModel.html Non sono in alcun modo contrario al modello anemico, ad esempio è una buona strategia per la programmazione funzionale. Solo non OOP.
—
ttulka,