Spring MVC 3 - привязка «неизменного» объекта к форме

Question

У меня есть несколько тщательно протестированных модульных классов DDD с тщательно отобранными модулями, с окончательными неизменяемыми инвариантами и проверками целостности. Реализация объекта происходит через адекватные конструкторы, статические фабричные методы и даже через Builders.

Теперь я должен предоставить форму Spring MVC для создания новых экземпляров некоторых классов.

Мне кажется (я не эксперт), что я должен предоставить пустой конструктор и установщики атрибутов для всех классов поддержки форм, которые я хочу связать.

Итак, что мне делать?

Создать анемичные объекты, предназначенные для поддержки форм, и перенести информацию в мою модель предметной области (так много для принципа СУХОЙ ...), вызывая соответствующие методы / конструктор?

Или есть механизмы, которые я пропустил, которые могут спасти мой день? :)

Заранее благодарим за мудрость!

Answer 1

Объекты, которые используются для связывания со слоями представления, обычно называются моделями представления, и они DTO предназначены для отображения данных, сопоставленных с объектами домена, и последующего отображения пользовательского ввода обратно в объекты домена.Модели представлений обычно выглядят очень похожими на объекты домена, которые они представляют, однако есть некоторые важные различия:

1. Данные из объектов домена могут быть сведены или иным образом преобразованы в соответствии с требованиями данного представления,Управлять отображением в простых объектах проще, чем отображать в структуре представления, такой как MVC.Проще отлаживать и обнаруживать ошибки.

2. Для данного представления могут потребоваться данные из нескольких объектов домена - не может быть одного объекта домена, который соответствует требованиям представления.Модель представления может быть заполнена несколькими объектами домена.

3. Модель представления обычно разрабатывается с учетом конкретной структуры представления и, как таковая, может использовать специфические для этой среды атрибуты для привязки и проверки на стороне клиента.,Как вы заявили, типичное требование - это конструктор без параметров, который подходит для модели представления.Опять же, гораздо проще тестировать и управлять моделью представления, чем какой-то сложный механизм отображения.

Представления моделей, по-видимому, нарушают принцип СУХОГО, однако после более пристального взгляда ответственностьмодель представления отличается, поэтому с учетом принципа единой ответственности 1020 * целесообразно иметь два класса.Также обратите внимание на эту статью, в которой обсуждается ошибка повторного использования, часто приводимая по принципу DRY.

Более того, модели представлений действительно анемичны, хотя в них может быть конструктор, принимающий объект домена.в качестве параметра и способа создания и обновления объекта домена с использованием значений в модели представления в качестве входных данных.По своему опыту я обнаружил, что хорошей практикой является создание класса модели представления для каждой сущности домена, которая будет отображаться на уровне представления.Управлять двойной иерархией классов доменных объектов и моделей представлений легче, чем управлять сложными механизмами сопоставления.

Обратите также внимание, что существуют библиотеки, которые пытаются упростить сопоставление между моделями представления и объектами домена дляпример AutoMapper для .NET Framework.

Answer 2

Я решил это, создав интерфейс DTO:

public interface DTO<T> {
    T getDomainObject();

    void loadFromDomainObject(T domainObject);
}

public class PersonDTO implements DTO<Person> {
    private String firstName;
    private String lastName;

    public PersonDTO() {
        super();
    }

    // setters, getters ...

    @Override
    public Person getDomainObject() {
        return new Person(firstName, lastName);
    }

    @Override
    public void loadFromDomainObject(Person person) {
        this.firstName = person.getFirstName();
        this.lastName = person.getLastName();
    }

    // validation methods, view formatting methods, etc
}

Это также предотвращает утечку информации о проверке и форматировании в модель предметной области. Мне очень не нравятся аннотации Spring (или других фреймворков) (@Value и т. Д.) И javax.validation в моих объектах домена.

Answer 3

Да, вам нужно будет создать объекты для формы, чтобы принимать все входные данные, и обновить вашу модель с помощью этих объектов за одну операцию.

Но я не буду называть эти объекты анемичными (особенно еслиDDD).Эти объекты представляют одну единицу работы.Так что это тоже доменные понятия!