EDUARD SAPOTSKIskyANAНе думаю, что доменные объекты у тебя прям в отчётах правятся.
Да легко. Предлагаешь юзеру по десятку справочников прогуляться что бы несколько значений изменить? Открой ту же 1С и удивись. Но да ладно...1С десктоп, где всё в памяти сидит? Или 1C веб? Открой Jira и Fiddler-ом посмотри.

Ну а если серъёзно. То что конкретно, какие объекты правит твой юзер через отчёты? Ты под каждую колонку свою хранимку пишешь?

EDUARD SAPOTSKIskyANAСледовательно пользователь из отчёта по ссылке переходит в заказ и правит заказ ( одна команда ). По другой ссылке переходит в справочник товаров и правит икру ( вторая команда ).
А теперь вопрос, чем это отличается от методов в обычном MVC контроллере или GRUD методов в WCF или хранимок и представлений на уровне БД? Тем что пытаемся разнести то что в принципе разнести не возможно?Вася, да прочитай ты статью и попытайся понять. Там же про эволюцию проекта от твоего уровня до реализации принципа CQRS (которому сто лет в обед) написано русским языком

EDUARD SAPOTSKIskyANAВы, парни, "Достоевского не читали но осуждаете"
Не Достоевский это, а очередная говноархитектура, которую обсуждать смысла нет.
Воображения не хватает где эта хрень может быть эфективнее дедовских методов.
Не понятно чего ты на нее ваще повелся.И тут у Эдуарда аргументы закончились. Всё, что не Сервелад и Хранимки, то говноархитектура

Вот только Эдуард получает гораздо меньше бабла, чем говноархитекторы вроде Бындю и Бертрана Мейера. Правдо оно и понятно, задачи-то другого уровня решает.

EDUARD SAPOTSKIskyANAНу а если серъёзно. То что конкретно, какие объекты правит твой юзер через отчёты? Ты под каждую колонку свою хранимку пишешь?
Епта, да при чем здесь отчеты? Про ключики в БД ченить слышал и нормализации там всякие? Информация о практически любой бизнес-сущности может храниться в нескольких таблицах, юзеру мы ее отображаем через джоин(или у тебя своя метода? ). При чем здесь хранимка? Я могу сделать представление в БД(вьюшку) и вытянуть его в ОРМ или слепить это представление на уровне самой ОРМ(модели edmx) и спокойно обновлять данные. Можно и хранимку написать, ради бога.
Вопрос в том, как ты будешь в показанной архитектуре делать обычный CRUD??? (То что можно юзера удалить из списка это я понял, только не впечатляет).Ты картинку видел?
Буковки MongoDB, Redis, Spinx о чём-нибудь говорят?
Какие джоины могут быть в реализации Command, или Query для тех данных, что хранятся в NoSQL хранилище, кэше, или базе поискового движка? :)
Но при этом клиенту абсолютно прозрачно, откуда тянутся данные. А в случае с DataSet-ом какая прозрачность, напомни-ка?

Но тебе ничего это не говорит ведь, да? У тебя всё вьюшки с ОРМ-ами.

А у кого-то система эволюционирует, становится распределённой. У кого-то так и остаётся на уровне хранимок и DataSet-ов.
И вот первые понимают Майера с Бындю, а вторые задают вопросы вроде твоих :)

МСУEDUARD SAPOTSKI Не в моде нынче говорят.
Какой-то пионерский шум на ровном месте :)Шум из авангарда. В арьергарде не разобрать, о чём он, это я уже понял :)

Алексей КskyANAНо при этом клиенту абсолютно прозрачно, откуда тянутся данные. А в случае с DataSet-ом какая прозрачность, напомни-ка?Не вижу принципиальной разницы, модель представлена DataSet-ом или чем-то ещё. На прозрачности не сказывается. :-)


vs

А теперь представь, что именно вот эта тваоя MyEntity переехала в MongoDB.

Данные взяли и смигрировали.
Потому как MyEntity ну гораздо удобнее хранить целым, собранным документом, а не раскиданным по 10 таблицам SQL Server-а.
Очень быстро доставать её разом из MongoDB (не тратя время на 10 джоинов) и очень быстро изменять.

Вариант с DataSet-ом после такой миграции придётся просто выкинуть. :) Так сказать, вымер в ходе эволюции.

EDUARD SAPOTSKIskyANAБуковки MongoDB, Redis, Spinx о чём-нибудь говорят?
Какие джоины могут быть в реализации Command, или Query для тех данных, что хранятся в NoSQL хранилище, кэше, или базе поискового движка? :)
Но при этом клиенту абсолютно прозрачно, откуда тянутся данные. А в случае с DataSet-ом какая прозрачность, напомни-ка?

Но тебе ничего это не говорит ведь, да? У тебя всё вьюшки с ОРМ-ами.

А у кого-то система эволюционирует, становится распределённой. У кого-то так и остаётся на уровне хранимок и DataSet-ов.
И вот первые понимают Майера с Бындю, а вторые задают вопросы вроде твоих :)
Да хватит звездеть о мега-нагруженных системах, как там все сложно... для желторотиков эти сопли оставь.
Давай пример составной бизнес-сущности, которую отдаешь юзеру, и покажи как над ней провести CRUD, или ставим крест на этой г-архитектуре и расходимся!Дак вот именно там всё просто. Потому как архитектура продумана.

Это у тебя же возникают вопросы типа: "Я нафигачил 20 отчётиков, как же они в рамках CQRS смогут работать?" :)

А твоя бизнес-сущность - это что? Часть DomainModel, или QueryModel? Давай сначала определимся. Пример про заказ и икру, разве не про бизнес-сущности заказ и товар? :)

Алексей КEDUARD SAPOTSKIМСУ, срач не из-за датасетов, а из-за этой хрени:
Да, из картинки не понятно что такое Query и QueryModel, не изображены слои логики и доступа к данным: репозитарии и прочее...

Да и хрен с ней. В наше время картинкорисователей больше чем программистов, на каждую глупость обращать внимание - нервов не хватит. :-)Ещё один осуждатель из нечитавших :)
Про репозиторий помнится в таком же духе писал. А сейчас ничего, пользуется :)

Алексей КskyANAпропущено...
А теперь представь, что именно вот эта тваоя MyEntity переехала в MongoDB.

Данные взяли и смигрировали.
Потому как MyEntity ну гораздо удобнее хранить целым, собранным документом, а не раскиданным по 10 таблицам SQL Server-а.
Очень быстро доставать её разом из MongoDB (не тратя время на 10 джоинов) и очень быстро изменять.

Вариант с DataSet-ом после такой миграции придётся просто выкинуть. :) Так сказать, вымер в ходе эволюции.DataSet нельзя заполнить в репозитарии данными из MongoDB? Вроде как миграция приведёт к необходимости переписывания только репозитария.Можно конечно, но это будет верх глуппости