Проектирование сообщений для уровня обслуживания

Question

Я собираюсь разработать небольшое приложение, которое должно состоять из сервера и богатого клиента. до сих пор я буду следовать следующим правилам дизайна:

не

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

Моя настоящая проблема (независимая от языка) заключается в том, что я понятия не имею, какое решение принять решение относительно дизайна сообщений (объекты ответа и запроса).

Должны ли они быть основаны на повторно используемых деталях (например, таких объектах данных, как 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; 
    } 
} 

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

В противном случае при проектировании полностью отдельных плоских объектов сообщения все данные будут расходящимися и потребуются большие накладные расходы - с обеих сторон.

Моя цель состоит в том, чтобы создать клиентское/серверное приложение, которое находится в фазе 1, определенно реализованное в однородной технологии (.NET Remoting или Java RMI), но с возможностью легко включать поддержку SOAP.

Answer 1

Определите два интерфейса: клиент и сервер, чтобы протокол и среда связи могли различаться (это полезно, например, для модульного тестирования связи только с буфером в памяти). Клиентский интерфейс может быть очень простым (on_message (MESSAGE_ID, NUM_OPS, OPS));

Для каждого сообщения вы можете создать или сгенерировать (см. Google's protocoll buffers) класс. Затем создайте MAP из Message_ID в Message Object. Объект сообщения будет проверять сообщение и выполнять относительное действие.