Модель предметной области и пользовательские интерфейсы

Question

Я не уверен, должен ли я использовать объекты пользовательского домена непосредственно в пользовательском интерфейсе. Например, я хочу спроектировать пользовательский интерфейс для пользователя объекта домена, который имеет идентификатор пользователя, имя, пароль и список ролей. Сущность разработана таким образом, что она никогда не может находиться в недопустимом состоянии (например, неверный пароль или пустой userId)

public class User {
    public User(String userId, String name, String password) {
        //Initialization and validation
    }

    public String getUserId {
        /*implementation*/
    }
    public void changePassword(String oldPassword, String newPassword) {
        /*Set new password if it complies with the rules
        and if the the old one is correct*/
    }

    public void setName(String Name) {
        /*implementation*/
    }
    public String getName() {
        /*implementation*/
    }

    public List<Role> getRoles() {
        /*implementation*/
    }

    public void addRole(Role role) {
        /*implementation*/
    }
}

Каков наиболее подходящий способ разработки пользовательского интерфейса?

1) Придерживайтесь модели домена: Дизайн 3 окна. Окно «Новый пользователь» создает нового пользователя с заданным userId, именем и паролем. Другое окно «Изменить пароль» для изменения пароля и другое «Изменить пользователя», которое позволяет изменять имя и роли существующего пользователя

2) Может быть желательно использовать только одно окно для создания пользователя с заданным userId, именем, паролем и списком ролей. Я должен иметь возможность добавлять роли, даже если я еще не набрал userId.

Вариант 1 проще всего реализовать, поскольку я могу напрямую использовать доменные объекты в пользовательском интерфейсе. Но пользовательские интерфейсы могут быть болезненными в использовании. Вариант 2 желателен, но объекты домена не могут быть использованы напрямую. Я не вижу, как я могу добавить роли, если пользователь еще не создан. Я не могу создать пользователя, потому что у меня может не быть правильной информации в данный момент, например, временное пустое текстовое поле, которое представляет идентификатор пользователя. Как мне этого добиться?

Единственное чистое решение, которое я могу придумать, - это создание классов для использования в пользовательском интерфейсе, которые будут имитировать информацию в реальных объектах домена. Так что я смогу создать пустого пользователя для добавления ролей, а затем установить userId после этого. Пользовательский интерфейс может использовать эту информацию для создания объекта реального домена.

Есть ли простой способ обойти это? Как это обычно делается?

Answer 1

Это много вопросов, но вы правы, когда задаете их, потому что они очень важны, когда вы начинаете смотреть, как передавать объекты между слоями.

Давайте начнем с

«Как это обычно делается?»

Вы справедливо отметили, что способ представления объекта домена пользователю не всегда в необработанном виде - иногда вы хотите показать его чуть меньше, как в примере с пользователем, где добавление ролей может в другом пользовательском интерфейсе, отличном от пользовательского создания / модификации, иногда вы хотите показать немного больше, отображая 2 объекта одновременно или представляя смешанные данные, например, из 2 объектов.

Кстати, небольшая точность: вы считаете, что вариант 1 (несколько окон) больше привязан к модели предметной области, хотя я думаю, что он имеет тенденцию имитировать модель меньше, поскольку он не представляет весь объект предметной области в одном экран, но это деталь.

Так как вы обычно справляетесь с этим? Точно так, как вы сказали, создавая специфичные для пользовательского интерфейса объекты, приспособленные для ваших представлений

Единственное чистое решение, о котором я могу подумать, - это создание классов для использования в пользовательский интерфейс, который будет имитировать информацию в реальном домене объекты. Так что я смогу создать пустого пользователя для добавления ролей, затем установите userId после этого.

Их часто называют DTO , объектами ViewModel в мире .NET / MVVM и т. Д.

Пользовательский интерфейс может использовать эту информацию для создания реального домена Objet.

Обычно сам пользовательский интерфейс не несет ответственности за создание / обновление объектов домена из объектов пользовательского интерфейса. Сопоставление выполняется в другом слое.

Теперь, когда мы увидели базовое решение, давайте посмотрим, как оно необычно удалось;)

Есть несколько альтернатив. Одним из них является шаблон Naked Objects , где все пользовательские интерфейсы являются прямыми представлениями объектов домена. Это сильно упрощает проблему, но еще предстоит выяснить, являются ли такие интерфейсы всегда лучшими с точки зрения рабочего процесса и простоты использования.

Или вы могли бы уйти, просто используя ваши доменные объекты на уровне представления. Это недавнее сообщение указывает на проблемы, которые возникают, когда у вас есть несколько представлений одного и того же объекта, и исследует возможность использования одних и тех же доменных объектов во всех слоях. Проблема здесь в том, что вам, возможно, придется втиснуть некоторые данные в объекты вашего домена, которые не связаны исключительно с доменом, и вам, возможно, придется отказаться и от некоторых инвариантов (например, «пользователь не может существовать, если ему не назначена роль» ", если вы разделяете пользовательский интерфейс создания и назначения ролей).

Наконец, чтобы вернуться к примеру пользователя / роли и «Я не вижу, как я могу добавить роли, если пользователь еще не создан»: вам не нужно иметь существующий объект User для конечного пользователя ваше приложение, чтобы иметь возможность выбирать роли. Вы можете просто выбрать роли на экране и удерживать их до тех пор, пока фактическое создание объекта User не будет завершено, и при этом применять все обязательные поля, такие как ID.

Answer 2

В чем проблема с вариантом 2?Вы можете сначала создать новый объект User, а затем добавить к нему правила.Если у вас нет всей необходимой информации для создания нового объекта «Пользователь» (например, пустое текстовое поле «ИД пользователя»), просто сообщите ему, что это поле необходимо заполнить.