Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Говнокод детектед. Как отобразить готовые к отгрузке заказы или ожидающие утверждения? Икапсуляция резко идет лесом.
А>Нет,если не знаешь как такие вещи реализуются читаем (например http://www.kitchaiyong.net/2009/10/repository-specification-unit-of-work.html) и понимает как это делается. Атрибуты сущности можно сделать публичными. Я не писал в переведенном примере идеальный код, а хотел показать только основные моменты.
Еще раз. Тот код что ты привел не позволит делать выборки нормально (тупо наложить фильтр на выборку не выйдет), или нарушится инкапсуляция, то есть в запросе ты будешь указывать совершенное внутренние детали объектов, или тебе придется отказаться от такого кода.
Поэтому такой код как ты привел в реальном проекте не встретится, цена ему — ноль.


G>>Кроме того абсолютно непонятно к чему этот код, думаешь в anemic не получится родить аналогичный функционал с меньшим количеством строк?
А>Пример.

class OrderService
{
   IQueryable<order> GetShipableOrders()
   {
       return from o in ordersRepo.Items
              where o.IsPayed
              select o;
   }

   void ShipOrder(int orderId)
   {
       var order = GetShipableOrders().Where(o => o.id == orderId).First();
       order.IsShipped = true;
       ordersRepo.Save(order);
   }
}

Причем тут уже реюз идет GetShipableOrders отдает запрос как для представления, так и для внутренней логики.



А>>>DВ анемике, ты все равно создашь методы для проверки, + если добавится иерархия заказов в rich просто переопределяется поведение, в анемике ты все равно создашь иерархию классов, и как пишешь
G>>Иерархию заказов ты придумал, в anemic она не появится, незачем.
А>Ну в заказах может и надуманна иерархия, но в реальных системах такого очень много.
Ты опять про дикое legacy, которое было написано до 2000 года? Там может быть и много, а в современных системах я не видел.


G>>>> Гораздо более плохой выход из ситуации множество иерархий объеденить в одну иерархию бизнес-объектов.
А>>>создашь 2 параллельных иерархии зависимых друг от друга.
G>>Это еще хуже чем одна толстая иерархия, потому что больше неявных связей. Формально SRP может и выполняется, но сильно нарушается OCP и дико растут метрики связности классов.
А>Так приведи пример реализации. И в твоем случае если требования для поведения Pay меняются ты нарушишь OCP.
Ниче я не нарушу, если требования меняются, то код меняется. Мои классы сервисов вообще не предназначены для расширения, большинство из них sealed.


А>>>В этом примитивном примере можно конечно все сделать "красиво" и в анемике, но жизнь сложна.
G>>То что сложно делается в anemic в rich получается еще сложнее. Обратных примеров я покачто не видел.
А>Я не говорю что Rich легче и меньше кода пишется, возможно поэтому его и меньше используют. Знаний нужно больше.
А в чем тогда преимущество? Тяжелее пишется, хуже работает, знаний нужно больше, больше кода... в чем профит?

А>>>Скорее всего для каких-то заказов, возможно для определенных клиентов можно отгружать и не оплаченные заказы. Потребители твоих объектов (доменные сервисы) ни когда об этом не узнают. А вот в анемике начинаются инжектирования, появляются ветвления для одного атрибута(состояния) в разных методах и т.д. В результате ты создаешь намного больше кода, логика разбросана по куче классов и как результат нет гарантии, что в методе сервиса не забудут добавить поведение.
G>>
G>>Ты правда считаешь что один-два if создает больше кода, чем наследование класса + переопределение методов + настройка маппинга для создание объекта нужного класса + создание параллельной иерархии для валидаторов или ещечегонить?
А>Ну если в системах которые ты пишешь возможен только 2 поведения тебе везет! Обычно все намного сложней.
Ну так я и говорю что используются стратегии. Они успешно инжектятся в классы сервисов.
А что в случае Rich делать? Плодить наследников под каждый вариант?
Или те же самые стратегии? То есть приводить к anemic

А>Давай примеры кода. Рассуждать можно много.
Так я тебе привел код, а ты привел что-то неправдоподобное, что в реальном проекте не будет существовать.
лучше ты приведи пример rich кода, которой хотябы немного сложнее тривиального, чтобы в нем не было критических недостатков. Желательно с кодом контроллера, который работает с объектами.

Здравствуйте, gandjustas, Вы писали:

G>Может и не на каждый чих, но у stakoverflow почти каждую секунду появляются вопросы\ответы и оценки, а если весь stakexchange рассмотреть, то там гораздо больше выйдет.
Судя по схеме их базы. У них нет сильно транзакционной логики. Основные операции это вставка в таблицы и простой поиск. В таком случае хранимки действительно не сильно и нужны.

G>некоторый "Банковский софт" умудряется тормозить при совершенно банальных операциях, вроде просмотра форм, двумя-тремя пользователями раз в минуту.
Думаю тут проблема в радиусе кривизны рук, а не в использовании/неиспользовании хранимок.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, gandjustas, Вы писали:

G>>Может и не на каждый чих, но у stakoverflow почти каждую секунду появляются вопросы\ответы и оценки, а если весь stakexchange рассмотреть, то там гораздо больше выйдет.
AJD>Судя по схеме их базы. У них нет сильно транзакционной логики. Основные операции это вставка в таблицы и простой поиск. В таком случае хранимки действительно не сильно и нужны.
А кто мешает сделать аналогичную схему для любого приложения? Изменять\добавлять\удалять в одной транзакции миллионы записей — пахнет идиотизмом.

G>>некоторый "Банковский софт" умудряется тормозить при совершенно банальных операциях, вроде просмотра форм, двумя-тремя пользователями раз в минуту.
AJD>Думаю тут проблема в радиусе кривизны рук, а не в использовании/неиспользовании хранимок.
Использование хранимок для всего обычно является следствием кривизны рук.

Здравствуйте, gandjustas, Вы писали:

G>А кто мешает сделать аналогичную схему для любого приложения? Изменять\добавлять\удалять в одной транзакции миллионы записей — пахнет идиотизмом.
Потому что не все задачи можно решить простым запросом, иногда нужно транзакционно обновлять данные в зависимости от кучи параметров. И на все это счастье не более 5-10 ms от начала запроса до момента использования готовых данных, включая сетевой раундтрип до SQL сервера.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, gandjustas, Вы писали:

G>>А кто мешает сделать аналогичную схему для любого приложения? Изменять\добавлять\удалять в одной транзакции миллионы записей — пахнет идиотизмом.
AJD>Потому что не все задачи можно решить простым запросом, иногда нужно транзакционно обновлять данные в зависимости от кучи параметров. И на все это счастье не более 5-10 ms от начала запроса до момента использования готовых данных, включая сетевой раундтрип до SQL сервера.

Пример такого? По-человечески обычно делается внешним процессом, а не в UI и сначала формируются данные для обновления, а потом операцией update (или merge) транзакционно заливаются в таблицу. Да вообще куча способов избежать диких тормозов для пользователя даже при сложной логике.

Здравствуйте, Cyberax, Вы писали:

C> Из топовых высоконагруженных сайтов архитектуру на хренимках вообще никто не строит (там вообще всё больше NoSQL).
NoSQL там больше для кеша, внизу все равно как правило реляционка.

C> Даже Stackoverflow с классической реляционной БД использует LINQ.
Но это не значит, что там нет хранимок. ))

Здравствуйте, IB, Вы писали:

C>> Из топовых высоконагруженных сайтов архитектуру на хренимках вообще никто не строит (там вообще всё больше NoSQL).
IB>NoSQL там больше для кеша, внизу все равно как правило реляционка.
С хренимками?

C>> Даже Stackoverflow с классической реляционной БД использует LINQ.
IB>Но это не значит, что там нет хранимок. ))
Я не думаю, что они там в качестве основы БЛ.

Здравствуйте, <Anonymous>, Вы писали:

C>>Ну оно и есть — legacy. Т.е. системы, которые развиваются часто ещё с 90-х годов.
A>Да, но я видел несколько довольно крупных legacy проектов, которые переводили на процедуры в наше время.
Я тоже видел крупные проекты, которые делали на хранимках, причем совсем недавно. Жуть еще та. Объясняется легко — народ в крупных конторах любит сидеть годами на попе ровно, не изучая ничего нового, в результате "пианист играет, как умеет". На вопрос "на кой вам хранимки?" следует аргументация 10-летней давности и убийственный довод "у нас так положено".

Здравствуйте, -VaS-, Вы писали:

NS>>Но лично я не представляю rich или DDD аппликэйшн в современных энерпрайз решениях. Везде и всегда анемик.

VS>Ну так DDD не есть особенно объектно-ориентированная. Чисто процедурный подход — гоняем голые данные между процедурами, скруппированными в "сервисы". Это и не плохо, и не хорошо, ибо для энтерпрайза сегодня это едва ли не единственно подходящее решение.

В DDD вся логика лежит в доменных объектах, то есть чистейший ООП. В нем выделяется некий операционный уровень, в котором находятся некие сервисы, но все эти сервисы просто раздают команды домену, и бизнес логики в них нет. Эрик Эванс именно об этом и говорит на протяжении всей книги, что ВСЯ логика лежит в домене.

Здравствуйте, AndrewJD, Вы писали:

G>>Думаешь в stackoverflow мало бл? Сильно ты заблуждаешься. Только stackoverflow держит бешеные нагрузки, а этот "legacy софт на ХП" падает при смешном количестве пользователей.
AJD>Все сильно зависит от типа нагрузки. Очень сильно сомневаюсь, что у stackoverflow на каждый чих производится транзакционная вставка и обновление кучи таблиц, как это происходит в банковском софте.
Классический банковский софт — это давно решённая и неинтересная проблема. Даже в крупных банках достаточно тупо поставить мощный сервер, а там дальше хоть хранимками делать. Сложного-то фундаментально в нём ничего нет.

Вот какой-нибудь софт для high-speed trading — другое дело. Там никакими хранимками и не пахнет.

Здравствуйте, olegkr, Вы писали:
C>>>Ну оно и есть — legacy. Т.е. системы, которые развиваются часто ещё с 90-х годов.
A>>Да, но я видел несколько довольно крупных legacy проектов, которые переводили на процедуры в наше время.
O>Я тоже видел крупные проекты, которые делали на хранимках, причем совсем недавно. Жуть еще та. Объясняется легко — народ в крупных конторах любит сидеть годами на попе ровно, не изучая ничего нового, в результате "пианист играет, как умеет". На вопрос "на кой вам хранимки?" следует аргументация 10-летней давности и убийственный довод "у нас так положено".

Не всегда. Часто называют другую причину: СУБД меняется намного реже чем платформа разработки. И приводят пример: 10 лет назад UI был на Delphi (классическом asp), сейчас на .net`е, еще через 10-15 лет .net и все ORM могут придать анафеме, а хранимки как работали так и работают. И тут уже тяжело с таким доводом спорить.

Здравствуйте, huligun, Вы писали:

H>Здравствуйте, -VaS-, Вы писали:

NS>>>Но лично я не представляю rich или DDD аппликэйшн в современных энерпрайз решениях. Везде и всегда анемик.

VS>>Ну так DDD не есть особенно объектно-ориентированная. Чисто процедурный подход — гоняем голые данные между процедурами, скруппированными в "сервисы". Это и не плохо, и не хорошо, ибо для энтерпрайза сегодня это едва ли не единственно подходящее решение.

H>В DDD вся логика лежит в доменных объектах, то есть чистейший ООП.
Ну "чистейший ООП" достижим и без столь злостного нарушения принципов дизайна.

H>В нем выделяется некий операционный уровень, в котором находятся некие сервисы, но все эти сервисы просто раздают команды домену, и бизнес логики в них нет. Эрик Эванс именно об этом и говорит на протяжении всей книги, что ВСЯ логика лежит в домене.

Если вся логика живет в домене, то домен также отвечает за загрузку сущностей, то есть должен иметь ссылки на репозитарии.
Если вся логика живет в домене, то часть её придется ручками дублировать на клиентской стороне для валидации.
Если вся логика живет в домене, то абсолютно непонятно куда помещать методы БЛ, которые работают сразу с несколькими сущностями.
Если вся логика живет в домене, то ты вынужден постоянно тянуть из базы всю запись, чтобы материализовать доменные объекты и тебе недоступны многие операции, вроде агрегации и соединений.

А оно вообще нужно? И какова цель? "ТруЪ ООП"?

Здравствуйте, Cyberax, Вы писали:

C>Вот какой-нибудь софт для high-speed trading — другое дело. Там никакими хранимками и не пахнет.

high-speed trading он тоже очень разный. Там где идет счет на микросекунды база никогда не стоит на пути ордера и сохранение в нее выполняется асинхронно. Тут нет никакой разницы хранимка или не хранимка и скорость пофигу.
Если, взять по-проще со скоростями 5-20 ms и с синхронным сохранением в базу — хранимки выгоднее. Слишком накладно несколько раз ходить в базу.

Здравствуйте, Cyberax, Вы писали:

C>С хренимками?
Да байт его знает ))

C>Я не думаю, что они там в качестве основы БЛ.
А про основу БЛ никто и не говорит. Просто утверждать, что хранимки прошлый век — тоже экстремизм. =)

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Cyberax, Вы писали:

C>>Вот какой-нибудь софт для high-speed trading — другое дело. Там никакими хранимками и не пахнет.

AJD>high-speed trading он тоже очень разный. Там где идет счет на микросекунды база никогда не стоит на пути ордера и сохранение в нее выполняется асинхронно. Тут нет никакой разницы хранимка или не хранимка и скорость пофигу.
AJD>Если, взять по-проще со скоростями 5-20 ms и с синхронным сохранением в базу — хранимки выгоднее. Слишком накладно несколько раз ходить в базу.

А в чем проблема батчить запросы?