Неполадка с архитектурой (слишком много) сложных объектов - PullRequest
Новая
       18

Неполадка с архитектурой (слишком много) сложных объектов

3 голосов
/ 22 июня 2011

Хорошо, я отвечаю как за сервер, так и за клиента (используется внутри) в этой архитектуре RESTful. (используя рестлет).

У нас есть ресурс, который предоставляет операцию Post. Вот упрощенная версия: 

public class UserResource {

    @Post
    public Representation create(UserRegistration registration) {
        SomeService.getInstance().createUser(registration);
        return new XstreamRepresentation(new RegistrationResponse(registration.getUniqueCode()););
    }

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

Теперь, когда мы должны документировать эти ресурсы и позволить другим клиентам использовать их, возникают некоторые "проблемы", которые заставляют меня думать, что этот API может быть слишком сложным.

Этот почтовый сервис, например. Внутренний метод принимает сложный тип UserRegistration 

public class UserRegistration implements Serializable {

    private Profile profile;
    private Boolean someBooleanProperty;

    public UserRegistration(Profile profile) {
        this(profile, true);
    }

    public Profile getProfile() {
        return profile;
    }

    public boolean isSomeBooleanProperty() {
        return someBooleanProperty;
    }

}

который, в свою очередь, использует другой сложный объект (профиль) 

public class Profile {

    private String nickname;
    private String email;
    private String password;
    private String firstname;
    private String lastname;
    private Date birthDate;
    private String phone;
    private Address address;
    private GenderType gender;
    private String subscriptionSite;
    private Date privacyAcceptanceDate;
    private Date subscriptionDate;
    private String activationCode;
    private String socialSecurityNumber;
    ...

, который использует много сложных типов и т. Д.

Такое использование сложных типов меня действительно беспокоит. Я либо не знаю, как это задокументировать (кроме составления длинного списка внутренних свойств этих сложных объектов), либо я просто потерян.

Мои вопросы: Должен ли я упростить? Эта архитектура очень плохо спроектирована? Могут ли несколько строитель методы сделать свое дело?

Ответы [ 2 ]

3 голосов
/ 22 июня 2011

Разделяя типы сущностей домена между клиентом и сервером, вы (не говоря уже о вас) полностью преодолели точку REST.Предполагается, что системы RESTful совместно используют только типы медиа и связи.Общий доступ к таким типам, как вы, намного проще с SOAP, потому что WSDL позволяет инструментам позаботиться о деталях синхронизации типов клиентов и серверов.

REST - это всего лишь уменьшение связи между клиентом и сервером, чтобы позволитьих развиваться самостоятельно.Очевидно, что если у вас большой набор общих типов, это будет сложно, поэтому у вас сейчас такое плохое предчувствие.

Решение, которое я принял для этой проблемы, заключается в определении двух типов носителей.Одним из них является своего рода контейнер данных общего объекта.Давайте назовем это BusinessDocument, а другой - BusinessLayout.Клиент использует BusinessDocument для извлечения всех данных с сервера, а BusinessLayout предоставляет информацию «привязки данных», чтобы клиент знал, где в моем пользовательском интерфейсе отображаются различные части бизнес-данных.

Делая это, яв состоянии построить клиента, который действительно не понимает специфику данных, с которыми он имеет дело, он просто знает, как отобразить его в пользовательском интерфейсе для взаимодействия с пользователем.Благодаря этому я могу использовать один тип носителя для описания сотен различных бизнес-объектов.

0 голосов
/ 23 июня 2011

Нет необходимости отдавать java-клиент внешним потребителям. Ваш API должен быть в состоянии ответить на любой Http-клиент. Тот факт, что существует Java-клиент, который совместно использует объект, может зависеть от разных факторов, но не должен влиять на то, как вы предоставляете свой REST API стороннему потребителю.

Поэтому я бы предложил начать писать чистый HTTP-клиент, использующий Apache Commons HTTP, чтобы посмотреть, как ведет себя ваш REST API.

Тот факт, что объекты сервера являются сложными, также не должен интересовать API. Если старая система была разработана для моделирования объекта вокруг данных, что я считаю плохой идеей, то это то, с чем вам придется иметь дело. Из REST API вы всегда получаете только текст, XML или JSON, и вам, в конечном счете, придется проанализировать его в вашем объекте Java, если у вас есть, например, система с поддержкой ORM + RDBMS. Если вы можете хранить Json, как в БД документа, у вас нет этой проблемы, но, опять же, это не касается REST API как такового, но вам нужен слой, который преобразует JSON в Java Object.

Рестлет помогает вам в этом, конечно, такой сложный объект нелегко автоматически преобразовать.

...