Incoding Rapid Development Framework ( part 2 CQRS )

[lair]

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.

[vkopachinsky]

Маленькая цитата из книжки 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
… А теперь Ваши аргументы, кроме «выделений»?

[lair]

реализация нашего CQRS не накладываете ни каких ограничений.

Это обман.

А теперь Ваши аргументы, кроме «выделений»?

Мои аргументы о чем?

[vkopachinsky]

Это обман.

Это Ваше мнение.

Мои аргументы о чем?

Чем N-layer лучше CQRS (нашей реализации)

[lair]

Это Ваше мнение.

Я наглядно продемонстрировал вам ограничения, налагаемые вашей реализацией (например, она не позволяет использовать DI).

Чем N-layer лучше CQRS (нашей реализации)

N-layer не может быть лучше или хуже CQRS, потому что это непротиворечивые вещи. Даже в вашей реализации CQRS больше одного слоя, а в реализации той же p&p — полный набор.

Правильный «противник» CQRS, с которым можно сранивать и считать плюсы/минусы — это CRUD.

[vkopachinsky]

Правильный «противник» 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. Кода больше, учитывая что это будет во всех классах, то в разы больше

[lair]

А может тогда лучше с CMS ?)

Нет, не лучше. CRUD — это семантически адекватное противопоставление CQRS; архитектурный стиль, в котором операции над данными и чтение данных логически объединены.

По Вашему мнению если зависимости в проекте не через ctor, то это плохой проект и архитектура.

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

Надо сказать, что это не единственное ограничение вашего фреймворка; например, вы требуете, чтобы все команды наследовались от предоставленного вами базового класса. Это тоже весьма существенное ограничение.

А вот споры «плохое это ограничение или хорошее» — это совершенно отдельная дискуссия. Важно, что они — ограничения — есть, хотя вы утверждаете обратное.