Comments 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.
Маленькая цитата из книжки 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
… А теперь Ваши аргументы, кроме «выделений»?
реализация нашего CQRS не накладываете ни каких ограничений.
Это обман.
А теперь Ваши аргументы, кроме «выделений»?
Мои аргументы о чем?
Это обман.
Это Ваше мнение.
Мои аргументы о чем?
Чем N-layer лучше CQRS (нашей реализации)
Это Ваше мнение.
Я наглядно продемонстрировал вам ограничения, налагаемые вашей реализацией (например, она не позволяет использовать DI).
Чем N-layer лучше CQRS (нашей реализации)
N-layer не может быть лучше или хуже CQRS, потому что это непротиворечивые вещи. Даже в вашей реализации CQRS больше одного слоя, а в реализации той же p&p — полный набор.
Правильный «противник» CQRS, с которым можно сранивать и считать плюсы/минусы — это CRUD.
Правильный «противник» 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. Кода больше, учитывая что это будет во всех классах, то в разы больше
А может тогда лучше с CMS ?)
Нет, не лучше. CRUD — это семантически адекватное противопоставление CQRS; архитектурный стиль, в котором операции над данными и чтение данных логически объединены.
По Вашему мнению если зависимости в проекте не через ctor, то это плохой проект и архитектура.
По моему мнению, если проект, позиционирующий себя как фреймворк общего пользования, не позволяет использовать произвольный стиль IoC, это ограничение этого проекта. И когда авторы этого проекта говорят, что их реализация не накладывает никаких ограничений, они либо просто не понимают, либо лукавят.
Надо сказать, что это не единственное ограничение вашего фреймворка; например, вы требуете, чтобы все команды наследовались от предоставленного вами базового класса. Это тоже весьма существенное ограничение.
А вот споры «плохое это ограничение или хорошее» — это совершенно отдельная дискуссия. Важно, что они — ограничения — есть, хотя вы утверждаете обратное.
Sign up to leave a comment.
Incoding Rapid Development Framework ( part 2 CQRS )