Есть N типов сущностей. Например, Товар, Заказ, Заказчик и Продавец. У
некоторых объектов данных сущностей могут срабатывать
разного рода события. Например, после покупки Заказчик может посмотреть счет, а может и сразу оплатить, не смотря в него. И наоборот, такое событие может быть привязано к Продавцу.
Собственно вопрос. Как реализовать такую модель, чтобы:
Все собития могли быть описаны в одном месте
Максимально абстрагировать код клиента (программа, работающая с этими сущностями) и код сервера (программа, реализующая эти сущности)
События можно привязывать от одной сущности к другой без изменения кода клиента и сервера
Здравствуйте, mikа, Вы писали:
M>Есть N типов сущностей. Например, Товар, Заказ, Заказчик и Продавец. У некоторых объектов данных сущностей могут срабатывать разного рода события. Например, после покупки Заказчик может посмотреть счет, а может и сразу оплатить, не смотря в него. И наоборот, такое событие может быть привязано к Продавцу.
M>Собственно вопрос. Как реализовать такую модель, чтобы:
M>
M>Все собития могли быть описаны в одном месте
M>Максимально абстрагировать код клиента (программа, работающая с этими сущностями) и код сервера (программа, реализующая эти сущности)
M>События можно привязывать от одной сущности к другой без изменения кода клиента и сервера
M>
На самомо деле, если расширить требования, например, для событий: join, fork, simple merge, exclusive choose итд, то получится целый workflow
, а тут и до BPEL-серверов недалеко
Так что ,IMHO, ты изобретаешь велосипед
Здравствуйте, Sergey Rizhkov, Вы писали:
SR>На самомо деле, если расширить требования, например, для событий: join, fork, simple merge, exclusive choose итд, то получится целый workflow , а тут и до BPEL-серверов недалеко
Слушаем
SR>Так что ,IMHO, ты изобретаешь велосипед
Да я ничего и не изобретаю, и вряд ли буду. Так, информацией обогощаюсь.
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Sergey Rizhkov, Вы писали:
SR>>На самомо деле, если расширить требования, например, для событий: join, fork, simple merge, exclusive choose итд, то получится целый workflow , а тут и до BPEL-серверов недалеко
M>Слушаем
Что именно ?
SR>>Так что ,IMHO, ты изобретаешь велосипед
M>Да я ничего и не изобретаю, и вряд ли буду. Так, информацией обогощаюсь.
Обогащаться — это правильно !
Здравствуйте, Sergey Rizhkov, Вы писали:
SR>Что именно ?
Хотел бы услышать, каким именно подходом реализовать описанную мною проблемы. Если не очень понятно, распишу на псевдо коде
Есть парочка сущностей (для простоты понимания я опишу тот сценарий, о котором упоминал в первом посте)
Закачик
{
ДобавитьЗаказВКаталог(Заказ заказ)
{
}
}
Заказ
{
Название,
Стоимость,
}
Теперь сценарий, когда Закачик смотри в счет после оформления заказа, и, если он превышает некий предел, перепроверяет некоторые сведения.
Закачик
{
КритическаяСумма Равна 50000 рублей
ДобавитьЗаказВКаталог(Заказ заказ)
{
Если заказ.Стоимость Больше КритическаяСумма
ПерепроверитьСведения
}
}
В данном случае логика запрограммирована в классе Закачик. Мне такой подход не нравиться тем, что идет совмещение бизнес-сущностие и бизнес-правил, которое в последствии приведет к загромождению кода сущностей. Ибо, действий очень много, и сами эти действия зависит от многих факторов, которые не всегда ограничиваются параметрами Заказчик.
Второй способ
заказчик.ДобавитьЗаказВКаталог = СделатьЗаказ
КритическаяСумма Равна 50000 рублей
Если заказчик.ПоследнийЗаказ.Стоимость Больше КритическаяСумма
ПерепроверитьСведения
Этот подход мне совсем не нравиться, ибо клиентская программа (а это именно ее код) не может ничего знать о таких специфичных вещах, как КритическаяСумма.
Вот, собственно, и описываемая проблема. Жду любые комментарии
SR>Обогащаться — это правильно !
Ну, не совсем, конечно, теоретическое обогащение
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Sergey Rizhkov, Вы писали:
SR>>Что именно ?
M>Хотел бы услышать, каким именно подходом реализовать описанную мною проблемы. Если не очень понятно, распишу на псевдо коде
M>Есть парочка сущностей (для простоты понимания я опишу тот сценарий, о котором упоминал в первом посте)
M>M>Закачик
M>{
M> ДобавитьЗаказВКаталог(Заказ заказ)
M> {
M> }
M>}
M>Заказ
M>{
M> Название,
M> Стоимость,
M>}
M>
M>Теперь сценарий, когда Закачик смотри в счет после оформления заказа, и, если он превышает некий предел, перепроверяет некоторые сведения.
M>M>Закачик
M>{
M> КритическаяСумма Равна 50000 рублей
M> ДобавитьЗаказВКаталог(Заказ заказ)
M> {
M> Если заказ.Стоимость Больше КритическаяСумма
M> ПерепроверитьСведения
M> }
M>}
M>
M>В данном случае логика запрограммирована в классе Закачик. Мне такой подход не нравиться тем, что идет совмещение бизнес-сущностие и бизнес-правил, которое в последствии приведет к загромождению кода сущностей. Ибо, действий очень много, и сами эти действия зависит от многих факторов, которые не всегда ограничиваются параметрами Заказчик.
M>Второй способ
M>M>заказчик.ДобавитьЗаказВКаталог = СделатьЗаказ
M>КритическаяСумма Равна 50000 рублей
M>Если заказчик.ПоследнийЗаказ.Стоимость Больше КритическаяСумма
M> ПерепроверитьСведения
M>
M>Этот подход мне совсем не нравиться, ибо клиентская программа (а это именно ее код) не может ничего знать о таких специфичных вещах, как КритическаяСумма.
M>Вот, собственно, и описываемая проблема. Жду любые комментарии
А ну теперь понятнее.
В данном случае мой предыдущий пост не в тему (про workflow), не совсем тебя понял.
Да мешать бизнес-сущности и логику это плохо.
Я бы на вскидку предложил использовать паттерн Стратегия, например:
public interface OrderStrategy {
public void addOrder (Order aOrder) ...
}
public class LimitedOrderStrategy implements OrderStrategy {
public void addOrder (Order aOrder) {
if (aOrder.getPrice() > .... {
...кидаешь эксепшн или еще что-то
}
}
}
public class UnlimitedOrderStrategy implements OrderStrategy {
public void addOrder (Order aOrder) {
..
}
}
public class Order {
}
public class Customer {
public void setOrderStrategy (OrderStrategy aStrategy) ...
public void addOrder (Order aOrder) {
orderStrategy.addOrder (aOrder) ...
}
}
SR>>Обогащаться — это правильно !
M>Ну, не совсем, конечно, теоретическое обогащение
