Я собираюсь разработать небольшое приложение, которое должно состоять из сервера и многофункционального клиента.
пока я буду следовать следующим рекомендациям по дизайну:
- никогда не выставлять доменные объекты клиенту
- инкапсуляция служебных сообщений в объекты ответа и запроса
- идентифицирует подпрограммы обслуживания на основе вариантов использования, чтобы они всегда были атомарными
Моя настоящая проблема (не зависящая от языка) заключается в том, что я понятия не имею, какое решение принять в отношении дизайна сообщений (объектов ответа и запроса).
должны ли они основываться на повторно используемых частях (например, объектах данных, таких как CustomerDTO или CustomerData) или каждое сообщение должно быть индивидуальным; возможно, используя вложенные классы для деталей и вложенных элементов).
Я знаю, что не каждый сценарий использования потребует или даже разрешит показ или изменение всех атрибутов задействованных объектов, что приводит к разработке, в которой несколько сообщений должны представлять собой закрытый набор классов.
что бы вы предложили?
С наилучшими пожеланиями,
agent_harris
EDIT:
, чтобы привести более подробный пример.
допустим, у нас есть следующий интерфейс:
interface CustomerService {
/**
* this use-case should return all necessary data to
* edit a customer record, including the associated
* invoice/delivery addresses
*/
CustomerRecordResponse getUserRecord(int userId);
}
теперь вопрос в том, как составить CustomerRecordResponse таким образом, чтобы его компоненты
можно использовать повторно, но не раскрывая слишком много информации для других вариантов использования, которые могут не
разрешить доступ или изменять определенные свойства.
Одна из моих мыслей состояла в том, чтобы ввести небольшие классы, которые могли бы быть расширены в случае необходимости.
например:
class CustomerData {
private String firstName;
private String lastName;
// ...
}
, который в основном представляет собой набор атрибутов (плоский объект).
теперь, когда дело доходит до атомарного редактирования полной записи, включая адрес, вариант
может быть расширен класс CustomerData (может быть локально как вложенный класс) до:
class CustomerRecordResponse {
// nested class:
class ExtendedCustomerData extends CustomerData {
private AddressCountryData[] addresses;
}
}
здесь я бы увидел преимущество в том, что я могу повторно использовать компоненты базового типа для подачи
уже существующий виджет пользовательского интерфейса, который, возможно, является частью композиции пользовательского интерфейса.
в противном случае при проектировании совершенно отдельных объектов плоских сообщений все данные будут расходиться, и потребуются большие накладные расходы - с обеих сторон.
Однако моя цель - разработать клиент-серверное приложение, которое на первом этапе обязательно будет реализовано.
в однородной технологии (.NET Remoting или Java RMI), но с возможностью простого включения поддержки SOAP.