Комментарии 7
CQRS на мой взгляд превосходит N-Layer, а также не имеет «противопоказаний» или «побочных эффектов», что делает его кандидатом на первый патрон в обойму,
Маленькая цитата из книжки Exploring CQRS and Event Sourcing (в консультативный состав которой входит, на минуточку, Грег Янг), выделение мое:
You should not use the CQRS pattern as part of your top-level architecture; you should implement the pattern only in those bounded contexts where it brings clear benefits.
0
Маленькая цитата из книжки Exploring CQRS and Event Sourcing (в консультативный состав которой входит, на минуточку, Грег Янг), выделение мое:
Может Event Sourcing и не все подходит, но реализация нашего CQRS не накладываете ни каких ограничений.
Возьмем «эпичный n-layer» UserService и 3 метода Add, Approve, Edit в одном классе, рассмотрим плюсы от CQRS
1. делим на 3 (это удобно) атомарные (это важно) Command.
2. Disaptcher дает централизацию и АОР
3. Можно использовать Command с другими Command в Composite
4. Наследование Command/Query, а не SuperServiceBase
… А теперь Ваши аргументы, кроме «выделений»?
0
реализация нашего CQRS не накладываете ни каких ограничений.
Это обман.
А теперь Ваши аргументы, кроме «выделений»?
Мои аргументы о чем?
0
Это обман.
Это Ваше мнение.
Мои аргументы о чем?
Чем N-layer лучше CQRS (нашей реализации)
0
Это Ваше мнение.
Я наглядно продемонстрировал вам ограничения, налагаемые вашей реализацией (например, она не позволяет использовать DI).
Чем N-layer лучше CQRS (нашей реализации)
N-layer не может быть лучше или хуже CQRS, потому что это непротиворечивые вещи. Даже в вашей реализации CQRS больше одного слоя, а в реализации той же p&p — полный набор.
Правильный «противник» CQRS, с которым можно сранивать и считать плюсы/минусы — это CRUD.
0
Правильный «противник» CQRS, с которым можно сранивать и считать плюсы/минусы — это CRUD.
А может тогда лучше с CMS ?)
Я наглядно продемонстрировал вам ограничения, налагаемые вашей реализацией (например, она не позволяет использовать DI).
По Вашему мнению если зависимости в проекте не через ctor, то это плохой проект и архитектура.
Ещё раз попытаюсь довести до Вас, то что IRepository доступен в рамках Command/Query в момент dispatcher.Push/Query, по этому нету ни какого смысла делать зависимость в конструктор.
Теперь пример для IExternalService, который надо получить в Command/Query.
Мой
public class MyCommand:CommandBase
{
public override void Execute()
{
var service = IoCFactory.Instance.TryResolve<IExternalService>();
}
}
Ваш
public class MyCommand:CommandBase
{
readonly IExternalService service;
public MyCommand(IExternalService service)
{
this.service = service;
}
public override void Execute()
{
}
}
С точки зрения того, как будет создаваться объект разницы, НО
1. Теперь Ваш вариант Command нельзя использовать сценариях (как удобно сразу asp.net mvc binding Command делать) сериализация / десериализация, потому что объект имеет конструктор без параметров.
примечание: если добавить пустой, то service будет null
2. Кода больше, учитывая что это будет во всех классах, то в разы больше
0
А может тогда лучше с CMS ?)
Нет, не лучше. CRUD — это семантически адекватное противопоставление CQRS; архитектурный стиль, в котором операции над данными и чтение данных логически объединены.
По Вашему мнению если зависимости в проекте не через ctor, то это плохой проект и архитектура.
По моему мнению, если проект, позиционирующий себя как фреймворк общего пользования, не позволяет использовать произвольный стиль IoC, это ограничение этого проекта. И когда авторы этого проекта говорят, что их реализация не накладывает никаких ограничений, они либо просто не понимают, либо лукавят.
Надо сказать, что это не единственное ограничение вашего фреймворка; например, вы требуете, чтобы все команды наследовались от предоставленного вами базового класса. Это тоже весьма существенное ограничение.
А вот споры «плохое это ограничение или хорошее» — это совершенно отдельная дискуссия. Важно, что они — ограничения — есть, хотя вы утверждаете обратное.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Incoding Rapid Development Framework ( part 2 CQRS )