Типичная реализация хранилища DDD выглядит не очень хорошо, например, save()метод:
package com.example.domain;
public class Product { /* public attributes for brevity */
public String name;
public Double price;
}
public interface ProductRepo {
void save(Product product);
}
Инфраструктурная часть:
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);
}
}
Такой интерфейс предполагает Productанемическую модель, по крайней мере, с геттерами.
С другой стороны, ООП говорит, что Productобъект должен знать, как сохранить себя.
package com.example.domain;
public class Product {
private String name;
private Double price;
void save() {
// save the product
// ???
}
}
Дело в том, что когда человек Productзнает, как сохранить себя, это означает, что код инфраструктуры не отделен от кода домена.
Может быть, мы можем делегировать сохранение другому объекту:
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();
}
Инфраструктурная часть:
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"));
}
}
Каков наилучший подход для достижения этого? Возможно ли реализовать объектно-ориентированный репозиторий?
6
ООП говорит, что объект Product должен знать, как спасти себя - я не уверен, что это действительно так ... ООП сама по себе на самом деле не диктует этого, это скорее проблема дизайна / шаблона (где DDD / что угодно - вы
—
-используется
Помните, что в контексте ООП речь идет об объектах. Просто объекты, а не постоянство данных. Ваше утверждение указывает, что состояние объекта не должно управляться вне самого себя, с чем я согласен. Репозиторий отвечает за загрузку / сохранение из некоторого уровня персистентности (который находится вне области ООП). Свойства и методы класса должны поддерживать свою собственную целостность, да, но это не означает, что другой объект не может быть ответственным за сохранение состояния. И геттеры, и сеттеры должны обеспечивать целостность входящих / исходящих данных объекта.
—
jleach
«это не означает, что другой объект не может быть ответственным за сохранение состояния». - Я этого не говорил. Важным утверждением является то, что объект должен быть активным . Это означает, что объект (и никто другой) может делегировать эту операцию другому объекту, но не наоборот: ни один объект не должен просто собирать информацию из пассивного объекта для обработки своей собственной эгоистичной операции (как в случае с репозиторием - с геттерами) , Я попытался реализовать этот подход в фрагментах выше.
—
ттулка
@jleach Вы правы, наше понимание ООП другое, для меня геттеры + сеттеры вообще не являются ООП, иначе мой вопрос не имел бы смысла. Все равно спасибо! :-)
—
ттулка
Вот статья о моей точке зрения: martinfowler.com/bliki/AnemicDomainModel.html Я не повторяю анемическую модель во всех случаях, например, это хорошая стратегия для функционального программирования. Просто не ООП.
—
ттулка