Typowa implementacja repozytorium DDD nie wygląda zbyt dobrze, na przykład save()metoda:
package com.example.domain;
public class Product { /* public attributes for brevity */
public String name;
public Double price;
}
public interface ProductRepo {
void save(Product product);
}
Część infrastruktury:
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);
}
}
Taki interfejs oczekuje, że Productbędzie to model anemiczny, przynajmniej z getterami.
Z drugiej strony OOP mówi, że Productobiekt powinien wiedzieć, jak się uratować.
package com.example.domain;
public class Product {
private String name;
private Double price;
void save() {
// save the product
// ???
}
}
Chodzi o to, że gdy Productumie się zapisać, oznacza to, że kod infrastruktury nie jest oddzielony od kodu domeny.
Może możemy przekazać zapisywanie innemu obiektowi:
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();
}
Część infrastruktury:
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"));
}
}
Jakie jest najlepsze podejście do tego? Czy można zaimplementować repozytorium obiektowe?
6
OOP mówi, że obiekt produktu powinien wiedzieć, jak się uratować - nie jestem pewien, czy to jest naprawdę poprawne ... OOP sam w sobie tak naprawdę nie dyktuje, to raczej problem z projektem / wzorcem (gdzie DDD / cokolwiek-ty -use wchodzi)
—
jleach
Pamiętaj, że w kontekście OOP chodzi o przedmioty. Tylko obiekty, a nie trwałość danych. Twoje stwierdzenie wskazuje, że stanem obiektu nie należy zarządzać poza sobą, z czym się zgadzam. Repozytorium jest odpowiedzialne za ładowanie / zapisywanie z jakiejś warstwy trwałości (która jest poza sferą OOP). Właściwości i metody klasy powinny zachować swoją integralność, tak, ale to nie znaczy, że inny obiekt nie może być odpowiedzialny za utrzymanie stanu. I pobierające i ustawiające mają zapewnić integralność przychodzących / wychodzących danych obiektu.
—
jleach
„nie oznacza to, że inny obiekt nie może być odpowiedzialny za utrzymanie stanu”. - Nie powiedziałem tego. Ważnym stwierdzeniem jest to, że obiekt powinien być aktywny . Oznacza to, że obiekt (i nikt inny) nie może przekazać tej operacji innemu obiektowi, ale nie na odwrót: żaden obiekt nie powinien po prostu zbierać informacji z obiektu pasywnego w celu przetworzenia własnej egoistycznej operacji (tak jak repozytorium zrobiłoby to z getterami) . Próbowałem zaimplementować to podejście we fragmentach powyżej.
—
ttulka
@jleach Masz rację, nasze niezrozumienie OOP jest inne, dla mnie getters + setters w ogóle nie są OOP, w przeciwnym razie moje pytanie nie miałoby sensu. Mimo wszystko dziekuję! :-)
—
ttulka
Oto artykuł o moim punkcie: martinfowler.com/bliki/AnemicDomainModel.html Nie jestem pewien , czy model anemiczny jest we wszystkich przypadkach, na przykład jest to dobra strategia programowania funkcjonalnego. Po prostu nie OOP.
—
ttulka