Здравствуйте, Аноним, Вы писали:
А>Допустим в приложении есть "независимые" части, одна отображает этих Customers, вторая редактирует. Т.е. если я при помощи второй части создал нового Customer, то вторая должно обновить свой вид. Все происходит в пределах одного запущенного приложения (а не разных приложений).
Я бы в качестве механизма взаимодействия выбрал что-нибудь на подобии Unity Event Broker Extension.
А>В общем, не могу прийти к окончательному решению, как осущестивить это взаимодействие двух частей, уведомление о том что данные изменились. У меня сейчас каждая независимая часть работает со своими экзеплярами CustomerService (точнее эти экземпляры создаются на ходу по мере надобности). Если бы существовал один сервис на все приложение я бы объявил события, увидомляющие об изменении данных
А вот для ответа на вопрос о том, кто и когда инициирует запуск события, нужно знать подробнее устройство ваших "независимых частей".
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Аноним, Вы писали:
А>>>skipped HL>>IMHO, разные экземпляры и stateless — это правильно. HL>>Взаимодействовать должны элементы клиентского приложения: т.е. редактор уведомляет компонент, отображающий список customerов, что есть изменения. А уже что он там будет делать с сервисами — его дело.
А>А как организовать лучше всего это взаимодействие двух разных представлений. Что бы они друг друга знали мне не нравится. Что доложно быть той прослойкой, которая должна уведомлять об изменениях, к которой подписаны два этих представления? Не будет ли она лишней? Как вписать ее в архитектуру?
Прослойкой должен быть контроллер\презентер\viewmodel.
Если уж не получается их сделать, то надо модифицировать модель, чтобы та кидала события об изменении данных.
Взаимодействие сервисов. Дизайн приложения
От:
Аноним
Дата:
24.09.10 07:55
Оценка:
Язык программирования c#.
Допустим есть некий сервис, интерфейс которого реализует CRUD методы некой сущности, допусти Customer:
class CustomerService {
public Customer CreateNew() {
// ...
}
public IEnumeration<Customer > GetCustomers() {
// ...
}
public void Save(Customer customer) {
// ...
}
// ...
}
В идеальном случае, сервисы должны быть по возможности бесстатусными, т.е. для клиента такого сервиса должно быть абсолютно паралельно, создается сервис каждый раз заного, или используется его бывший экземпляр.
Допустим в приложении есть "независимые" части, одна отображает этих Customers, вторая редактирует. Т.е. если я при помощи второй части создал нового Customer, то вторая должно обновить свой вид. Все происходит в пределах одного запущенного приложения (а не разных приложений).
В общем, не могу прийти к окончательному решению, как осущестивить это взаимодействие двух частей, уведомление о том что данные изменились. У меня сейчас каждая независимая часть работает со своими экзеплярами CustomerService (точнее эти экземпляры создаются на ходу по мере надобности). Если бы существовал один сервис на все приложение я бы объявил события, увидомляющие об изменении данных
PS: Пологаю, перенесут в Архитектуру, но до этого хотелось бы услышать мнения .NET программистов
24.09.10 14:29: Перенесено модератором из '.NET' — TK
Здравствуйте, Аноним, Вы писали:
А>skipped
IMHO, разные экземпляры и stateless — это правильно.
Взаимодействовать должны элементы клиентского приложения: т.е. редактор уведомляет компонент, отображающий список customerов, что есть изменения. А уже что он там будет делать с сервисами — его дело.
Re[2]: Взаимодействие сервисов. Дизайн приложения
От:
Аноним
Дата:
24.09.10 08:23
Оценка:
А>>skipped HL>IMHO, разные экземпляры и stateless — это правильно. HL>Взаимодействовать должны элементы клиентского приложения: т.е. редактор уведомляет компонент, отображающий список customerов, что есть изменения. А уже что он там будет делать с сервисами — его дело.
А как организовать лучше всего это взаимодействие двух разных представлений. Что бы они друг друга знали мне не нравится. Что доложно быть той прослойкой, которая должна уведомлять об изменениях, к которой подписаны два этих представления? Не будет ли она лишней? Как вписать ее в архитектуру?
Re[4]: Взаимодействие сервисов. Дизайн приложения
От:
Аноним
Дата:
24.09.10 08:57
Оценка:
G>Прослойкой должен быть контроллер\презентер\viewmodel.
G>Если уж не получается их сделать, то надо модифицировать модель, чтобы та кидала события об изменении данных.
Как таковой модели нет. Есть контроллер, который тягает методы сервисов (наверное это является viewmodel). Так вот эта модель отображает список Customers. По определенной команде подымается форма, где происходит редактирование/или не происходит. Эта форма больше никаких связей к "главной модели не имеет". И я первначально не хотел их создавать. Сейчас лучшее что приходит в голову, подписываться на событие закрытия формы редактирования и обновлять список в "главной" модели
Здравствуйте, Аноним, Вы писали:
А>По определенной команде подымается форма, где происходит редактирование/или не происходит
Кто дает команду?
Re[6]: Взаимодействие сервисов. Дизайн приложения
От:
Аноним
Дата:
24.09.10 09:10
Оценка:
HL>Кто дает команду?
Ну вообще-то пользователь, через "главный" контролер. Пока вызов этой формы-редактирования реализован непосредственно в контроллере, позже хотел выделить в комманду (имеется ввиду паттерн команды).
G>>Прослойкой должен быть контроллер\презентер\viewmodel.
G>>Если уж не получается их сделать, то надо модифицировать модель, чтобы та кидала события об изменении данных.
А>Как таковой модели нет.
Моделью называется вче что лежит "ниже" слоя UI. Фактически твои сервисы — модель.
А>Есть контроллер, который тягает методы сервисов (наверное это является viewmodel).
Нет, viewmodel — это из другой оперы.
А>Так вот эта модель отображает список Customers. По определенной команде подымается форма, где происходит редактирование/или не происходит. Эта форма больше никаких связей к "главной модели не имеет". И я первначально не хотел их создавать. Сейчас лучшее что приходит в голову, подписываться на событие закрытия формы редактирования и обновлять список в "главной" модели
Сделай отдельный сервис событий (Event Broker), через который будешь прокидывать события изменений.
Re[6]: Взаимодействие сервисов. Дизайн приложения
От:
Аноним
Дата:
24.09.10 09:47
Оценка:
G>Сделай отдельный сервис событий (Event Broker), через который будешь прокидывать события изменений.
Спасибо за наводку, буду разбираться что такое Event Broker
Re[2]: Взаимодействие сервисов. Дизайн приложения
От:
Аноним
Дата:
24.09.10 10:26
Оценка:
_FR>Я бы в качестве механизма взаимодействия выбрал что-нибудь на подобии Unity Event Broker Extension.
Спасибо за конкретную ссылку
_FR>А вот для ответа на вопрос о том, кто и когда инициирует запуск события, нужно знать подробнее устройство ваших "независимых частей".
Устройство очень простое: Существует нечто вроде контроллекра, что дергает CRUD-подобный сервис для получения списка Customers и отображения его в гриде. Есть кнопка, по нажатию которой отображается окно для добавления нового Customers, эта форма работает со своим экземпляром CRUD-сервиса. После добавления пользователя, должен обновиться список на главной форме.
Здравствуйте, Аноним, Вы писали:
_FR>>А вот для ответа на вопрос о том, кто и когда инициирует запуск события, нужно знать подробнее устройство ваших "независимых частей". А>Устройство очень простое: Существует нечто вроде контроллекра, что дергает CRUD-подобный сервис для получения списка Customers и отображения его в гриде. Есть кнопка, по нажатию которой отображается окно для добавления нового Customers, эта форма работает со своим экземпляром CRUD-сервиса. После добавления пользователя, должен обновиться список на главной форме.
А просто после нажатия на кнопку на форме со списком нельзя ли установить, что изменения были сделаны (ShowDialog обычно возвращает некое значение, по которому это и определяют) и инициировтаь обновление данных?
Но если всё сложно (в смысле, "по науке" и отвязано друг от друга) то контроллер "окна для добавления нового Customers" должен опубликовать сообщение, а контроллер "для получения списка Customers и отображения его в гриде" отреагировать и обновить вью.
Help will always be given at Hogwarts to those who ask for it.
Re[4]: Взаимодействие сервисов. Дизайн приложения
От:
Аноним
Дата:
24.09.10 12:05
Оценка:
_FR>А просто после нажатия на кнопку на форме со списком нельзя ли установить, что изменения были сделаны (ShowDialog обычно возвращает некое значение, по которому это и определяют) и инициировтаь обновление данных?
_FR>Но если всё сложно (в смысле, "по науке" и отвязано друг от друга) то контроллер "окна для добавления нового Customers" должен опубликовать сообщение, а контроллер "для получения списка Customers и отображения его в гриде" отреагировать и обновить вью.
В принципе мне сейчас стало это понятно, но только после уточнения gandjustas, что "Прослойкой должен быть контроллер\презентер\viewmodel.".