Прочитал здесь про liabilities anemic
и не понял пункт

"It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places)."

а как тогда быть уверенным в том, что объект не изменился после вызова сервиса валидации объекта?

также не понял вот этот пункт

Necessitates a global access to internals of shared business entities increasing coupling and fragility.

как это проявляется повышение связанности сущностей?

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

S>а как тогда быть уверенным в том, что объект не изменился после вызова сервиса валидации объекта?

Лично я использую immutable entities...

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

S>Прочитал здесь про liabilities anemic

Лучше поискать другой источник иформации, чем эта статья в wiki.
ИМХО, она не адекватна

Liabilities
Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.

Что такое "truly object-oriented"? Есть какая-то формальная метрика определяющая насколько код есть труъ object-oriented?

Violation of the encapsulation and information hiding principles.

Это не соотвествует действительности.

Necessitates a separate business layer to contain the logic otherwise located in a domain model.

Ничего плохого в отделении мух от котлет я не вижу

It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).

??? Ерунда какая-то. В реальности один и тот же обьект может быть валидным и не валидным, в зависимости от контекста. Как раз реализация валидации в анемичной модели гораздо более удобная и логичная.

Necessitates a global access to internals of shared business entities increasing coupling and fragility.

С точностью наоборот. Анемик модель значительно уменьшает связность. Поскольку в обьектах нет бизнес логики, в анемик модели легко использовать "Single responsibility principle".

Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.

Конечно, использование универсальных всемогутеров увеличивает повторное использование кода, а маленькие без лишних зависимостей уменьшает

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

Подскажите, где можно посмотреть несложный пример с использованием анемика?

Сегодня был приятно удивлен, отношением Фаулера к anemic'у. Он называет его анти-паттерном.
http://www.martinfowler.com/bliki/AnemicDomainModel.html

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

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

Тогда уж скорее сценарий транзакций(Transaction Script).

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

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

А>Тогда уж скорее сценарий транзакций(Transaction Script).

Нет, не Transaction Script, потому что ему вообще доменная модель не нужна. И с таким мне бы не хотелось работать.
Все же если по Фаулеру, то я хотел сказать, что в энтерпрайз решениях преобладает Domain Model, но она везде и всегда анемик.

А вот рич я к сожалению не встречал в энтерпрайзе. И мне сложно представить как бы все это выглядело. То есть чтобы ВСЯ логика была в домене. Не в домене только инфраструктура и тонкая прослойка, типа фасада, которая бы раздавал доменным объекты команды. DDD в общем.

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

S>Прочитал здесь про liabilities anemic
S>и не понял пункт

S>

S>"It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places)."

S>а как тогда быть уверенным в том, что объект не изменился после вызова сервиса валидации объекта?

А ты не передаватй изменяющиеся объекты туда-сюда. Пусть сервис БЛ получает от PL идентификаторы объектов или критерии выборки, внутри себя изменяет все что надо и сохраняет объеты.

Rich

Controller:

//...
var order = ordersRep.Get(orderId);
var product = productRep.GetProduct(productId);
order.AddLine(new OrderLine(product, quantity));
ordersRep.Save(order);
//...

Domain:

class OrderLine
{
    public OrderLine(Product product, int quantity)
    {
        this.Product = product;
        this.Quantity = quantity;
        this.Price = product.Price; //Тип сложная БЛ
    }
    //....    
}

class Order
{
    public void AddLine(OrderLine line)
    {
        var sum = this.Lines.Sum(l => l.Price * l.Quantity);
        if(sum+line.Product.Price > 10000) //Типа валидация
        { 
            throw new Exception("Order is too large"); 
        }
        this.Lines.Add(line);
    }
}

Anemic

//...
orderService.AddLineToOrder(orderId, productId, quantity);
//...

class OrderService
{
    orderService.AddLineToOrder(int orderId, int productId, int quantity)
    {
        var productPrice = (from p in productRep.Items
                            where p.Id == productId
                            select p.Price).First();
        var sum = (from ol in orderLinesRep.Items
                   where ol.OrderId == orderId
                   select l.Price * l.Quantity).Sum();
        if(sum+productPrice > 10000) //Типа валидация
        { 
            throw new Exception("Order is too large"); 
        }
        
        orderLinesRep.Add(new OrderLine {Orderid = orderId, ProductId = productId, Price = productPrice } );
    }
}

Вроде код похож, НО
1)В Rich логика конкретного действия размазана по нескольким классам
2)Чтобы логика в Rich работала нужен зачатую LazyLoad, который очень губителен для быстродействия

S>также не понял вот этот пункт
S>

S>Necessitates a global access to internals of shared business entities increasing coupling and fragility.

S>как это проявляется повышение связанности сущностей?

Вообще-то никак.

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

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

А>Тогда уж скорее сценарий транзакций(Transaction Script).

Transaction Script — херня придуманная фаулером и им же обосранная. Реально так никто не пишет и видимо никогда не писал. Люди используют обычные функции для декомпозиции логики, это собственно и есть anemic: функции и данные.

G>Transaction Script — херня придуманная фаулером и им же обосранная. Реально так никто не пишет и видимо никогда не писал. Люди используют обычные функции для декомпозиции логики, это собственно и есть anemic: функции и данные.
Тогда что за патерн такой когда вся бизнеслогика в БД, а коде только вызовы процедур + немного логики по отображению во View?
Domain Model?

>1)В Rich логика конкретного действия размазана по нескольким классам
Нет это SRP. А что ты сделаешь если нужно переопределить поведение для кого-нибудь особенного ордера, скажем изменить валидацию?
В Rich просто создашь подкласс SuperOrder и переопределишь поведение. А в анемике у тебя появятся или ветвления в методе или создашь 2 полиморфных метода для каждого типа. А когда дабавиться еще какой-нибудь подтип и кто-то обязательно забудет дополнить код в сервисе.

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

G>>Transaction Script — херня придуманная фаулером и им же обосранная. Реально так никто не пишет и видимо никогда не писал. Люди используют обычные функции для декомпозиции логики, это собственно и есть anemic: функции и данные.
А>Тогда что за патерн такой когда вся бизнеслогика в БД, а коде только вызовы процедур + немного логики по отображению во View?
А>Domain Model?

Это может быть и то и другое. Rich и Anemic — о способе структурирования кода, а не том где будут запросы.

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

>>1)В Rich логика конкретного действия размазана по нескольким классам
А>Нет это SRP.
Где там SRP, если в Rich вся валидация и БЛ лежит внутри класса? Это как раз Anti-SRP.

А>А что ты сделаешь если нужно переопределить поведение для кого-нибудь особенного ордера, скажем изменить валидацию?
Добавлю условие в метод, если таких правил образуется множество, то сделаю инъекцию правил в сервис формирования ордеров.

А>В Rich просто создашь подкласс SuperOrder и переопределишь поведение.
А если тип ордера меняется в время его жини что тогда? (а вероятнее всего так и будет, заранее ты не скажешь)

А>А в анемике у тебя появятся или ветвления в методе или создашь 2 полиморфных метода для каждого типа. А когда дабавиться еще какой-нибудь подтип и кто-то обязательно забудет дополнить код в сервисе.
Не-а, см выше.

В случае изменяющегося набора правил что с ними делать в Rich? Инжектить в domain object? Когда инжектить? А если сериализация используется?
Ну его нафиг, Rich очень быстро превращается в неподьемного монстра при увеличении сложности.

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

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

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

А>Нет это SRP. А что ты сделаешь если нужно переопределить поведение для кого-нибудь особенного ордера, скажем изменить валидацию?
А>В Rich просто создашь подкласс SuperOrder и переопределишь поведение.
А>А в анемике у тебя появятся или ветвления в методе или создашь 2 полиморфных метода для каждого типа.
В анемике я бы сделал иерархию валидаторов.

G>Это может быть и то и другое. Rich и Anemic — о способе структурирования кода, а не том где будут запросы.

Если БЛ весь в процедурах, то ни какой домен тебе не нужен, что в нем будет?
Если взять твой пример, то на Transaction Script будет примерно такой код:

class OrderService
{
    orderService.AddLineToOrder(int orderId, int productId, int quantity)
    {
        //намеренно опускаю абстракцию доступа данных
        //вызываем хранимку, которая выполняет всю логику по добавлению.
        exec("AddLineToOrder",orderID,productId,quantity);
    }
}

Я не агитирую за такой подход, но большинство web приложений и приложений работающих под большой нагрузкой (сотни транзакций в секунду) работают именно на TS.

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

G>>Это может быть и то и другое. Rich и Anemic — о способе структурирования кода, а не том где будут запросы.

А>Если БЛ весь в процедурах, то ни какой домен тебе не нужен, что в нем будет?
Смотря какие процедуры, многие ORM вполне спокойно мапят CRUD для сущностей на процедуры.

А>Если взять твой пример, то на Transaction Script будет примерно такой код:
А>

А>class OrderService
А>{
А>    orderService.AddLineToOrder(int orderId, int productId, int quantity)
А>    {
А>        //намеренно опускаю абстракцию доступа данных
А>        //вызываем хранимку, которая выполняет всю логику по добавлению.
А>        exec("AddLineToOrder",orderID,productId,quantity);
А>    }
А>} 
А>

Возможно, но я так не пишу. И не знаю никого кто так пишет.

А>Я не агитирую за такой подход, но большинство web приложений и приложений работающих под большой нагрузкой (сотни транзакций в секунду) работают именно на TS.
stackoverflow работает под большой нагрузкой, но использует Linq2SQL
То что ты пишешь было правдой 15 лет назад.

G>Где там SRP, если в Rich вся валидация и БЛ лежит внутри класса? Это как раз Anti-SRP.
БЛ да, а валидациию можно убрать в другой объект, примеров масса. Об этом можно долго спорить.

А>>А что ты сделаешь если нужно переопределить поведение для кого-нибудь особенного ордера, скажем изменить валидацию?
G>Добавлю условие в метод, если таких правил образуется множество, то сделаю инъекцию правил в сервис формирования ордеров.

Вот уже пошли классы, классы...См: http://rsdn.ru/forum/design/4230324.1.aspx

Автор: gandjustas
Дата: 12.04.11

G>Вроде код похож, НО
G>1)В Rich логика конкретного действия размазана по нескольким классам

И в твоем случае,если логика становится немного сложнее код размазывается по классам.


А>>В Rich просто создашь подкласс SuperOrder и переопределишь поведение.
G>А если тип ордера меняется в время его жини что тогда? (а вероятнее всего так и будет, заранее ты не скажешь)
Сказать не могу, но если такое поведение возможно, то есть замечательный патерн state. Используя его я могу менять поведение объекта.

А>>А в анемике у тебя появятся или ветвления в методе или создашь 2 полиморфных метода для каждого типа. А когда дабавиться еще какой-нибудь подтип и кто-то обязательно забудет дополнить код в сервисе.
G>Не-а, см выше.
Вот-вот.

G>В случае изменяющегося набора правил что с ними делать в Rich? Инжектить в domain object? Когда инжектить? А если сериализация используется?
G>Ну его нафиг, Rich очень быстро превращается в неподьемного монстра при увеличении сложности.
Можно пример.

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

G>>Где там SRP, если в Rich вся валидация и БЛ лежит внутри класса? Это как раз Anti-SRP.
А>БЛ да, а валидациию можно убрать в другой объект, примеров масса. Об этом можно долго спорить.
Ну так если все убрать, то и получится anemic.

Было

class SomeDomainObject
{
    void SomeDomainMethod()
    {
        SomeValidation();
        SomeLogic();
    }
}

class Cotroller
{
    void SomeAction()
    {
        var o = repo.Get(id);
        o.SomeDomainMethod();
        repo.Save(o);
    }
}

Выносим валидацию и БЛ:

class SomeDomainObject
{
    void SomeDomainMethod()
    {
        validationService.SomeValidation(this);
        bllService.SomeLogic(this);
    }
}

class Cotroller
{
    void SomeAction()
    {
        var o = repo.Get(id);
        o.SomeDomainMethod();
        repo.Save(o);
    }
}

Убираем лишний уровень косвенности

class Cotroller
{
    void SomeAction()
    {
        var o = repo.Get(id);
        validationService.SomeValidation(o);
        bllService.SomeLogic(o);
        repo.Save(o);
    }
}

После этого оптимизируем запросы, чтобы не поднимать целые объекты из базы, а только необходимое.
Для целей реюза кода делаем extract method, сходные методы группируем в классы. Получили anemic.

Я всегда говорил что правильный rich — это anemic

А>>>А что ты сделаешь если нужно переопределить поведение для кого-нибудь особенного ордера, скажем изменить валидацию?
G>>Добавлю условие в метод, если таких правил образуется множество, то сделаю инъекцию правил в сервис формирования ордеров.

А>Вот уже пошли классы, классы...См: http://rsdn.ru/forum/design/4230324.1.aspx

Автор: gandjustas
Дата: 12.04.11

G>>Вроде код похож, НО
G>>1)В Rich логика конкретного действия размазана по нескольким классам
А>И в твоем случае,если логика становится немного сложнее код размазывается по классам.
Если ситуация когда правила часто меняются и вызывающий код не может делать предположений о структуре правил, то это нормальный tradeoff.
А что делать в случае Rich?


А>>>В Rich просто создашь подкласс SuperOrder и переопределишь поведение.
G>>А если тип ордера меняется в время его жини что тогда? (а вероятнее всего так и будет, заранее ты не скажешь)
А>Сказать не могу, но если такое поведение возможно, то есть замечательный патерн state. Используя его я могу менять поведение объекта.
То есть у тебя будет один класс, который в зависимости от некоторого предиката будет вызывать некоторый код BL.
У меня будет тоже самое, только вызов будет идти не через domain object, а сразу из сервиса (контроллера).


G>>В случае изменяющегося набора правил что с ними делать в Rich? Инжектить в domain object? Когда инжектить? А если сериализация используется?
G>>Ну его нафиг, Rich очень быстро превращается в неподьемного монстра при увеличении сложности.
А>Можно пример.
Лениво писать, ты же выше привел свои мысли по моим рассуждениям о выносе правил из метода, сделай тоже самое в случае rich.

G>Смотря какие процедуры, многие ORM вполне спокойно мапят CRUD для сущностей на процедуры.
Ты не ответил на вопрос, что будет в коде, если весь БЛ в процедурах.

G>Возможно, но я так не пишу. И не знаю никого кто так пишет.
Я тебя удивлю, но очень многие.


А>>Я не агитирую за такой подход, но большинство web приложений и приложений работающих под большой нагрузкой (сотни транзакций в секунду) работают именно на TS.
G>stackoverflow работает под большой нагрузкой, но использует Linq2SQL
G>То что ты пишешь было правдой 15 лет назад.
Посмотри на http://ormeter.net/ и увидишь разницу в материализации с ORM и без.

AJD>В анемике я бы сделал иерархию валидаторов.
Поведение объекта обычно не заканчивается валидацией, и почти на каждое(считай метод или логическую группу методов) тебе придется писать иерархию.
Выход, но наверно не очень.

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

А>>>Я не агитирую за такой подход, но большинство web приложений и приложений работающих под большой нагрузкой (сотни транзакций в секунду) работают именно на TS.
G>>stackoverflow работает под большой нагрузкой, но использует Linq2SQL
G>>То что ты пишешь было правдой 15 лет назад.
А>Посмотри на http://ormeter.net/ и увидишь разницу в материализации с ORM и без.
И что дальше? В Правильном(тм) приложении для типичной странички должно быть достаточно материализовать пару-тройку десятков объектов. Так что оверхед от ORM становится не таким серьёзным.

G>Убираем лишний уровень косвенности
G>

G>class Cotroller
G>{
G>    void SomeAction()
G>    {
G>        var o = repo.Get(id);
G>        validationService.SomeValidation(o);
G>        bllService.SomeLogic(o);
G>        repo.Save(o);
G>    }
G>}
G>

G>После этого оптимизируем запросы, чтобы не поднимать целые объекты из базы, а только необходимое.
G>Для целей реюза кода делаем extract method, сходные методы группируем в классы. Получили anemic.
Еще пару взмахов кисти: убираем все в хранимку, вместо сущностей используем ViewModel и вот он TS.

C>И что дальше? В Правильном(тм) приложении для типичной странички должно быть достаточно материализовать пару-тройку десятков объектов. Так что оверхед от ORM становится не таким серьёзным.
А зачем создавать кучу "не нужных" объектов. Т.к. из всех этих объектов все равно будут созданы DTO\ViewModel?
Я еще раз подчеркну, что я не сторонник хранения БЛ в процедурах. И тоже считаю, что расходы на создание объектов мизерны. Но вот пишут приложения на хранимках и TS.

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

AJD>>В анемике я бы сделал иерархию валидаторов.
А>Поведение объекта обычно не заканчивается валидацией, и почти на каждое(считай метод или логическую группу методов) тебе придется писать иерархию.
А>Выход, но наверно не очень.
Вот именно что "Поведение объекта обычно не заканчивается валидацией". И если все это поведение запихать в один ордер — тоже ничего хорошего не будет. Получится что-то типа: SuperOrder, SuperOrder2, SuperOrderNotSent, SimpleOrderWithPearlButton.
В анемике будет набор различных сервисов отвечающих за _конкретное_ действие. Как реализован валидатор через иерархию или ветвлением в методе — не столь существенно.

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

C>>И что дальше? В Правильном(тм) приложении для типичной странички должно быть достаточно материализовать пару-тройку десятков объектов. Так что оверхед от ORM становится не таким серьёзным.
А>А зачем создавать кучу "не нужных" объектов. Т.к. из всех этих объектов все равно будут созданы DTO\ViewModel?
Для удобства. За тем же, зачем сейчас программы не пишут на ассемблере.

А>Я еще раз подчеркну, что я не сторонник хранения БЛ в процедурах. И тоже считаю, что расходы на создание объектов мизерны. Но вот пишут приложения на хранимках и TS.
Кто "пишут"? Поимённо, пожалуйста.

Хренимые процедуры сейчас явно уходят в legacy. Из топовых высоконагруженных сайтов архитектуру на хренимках вообще никто не строит (там вообще всё больше NoSQL). Даже Stackoverflow с классической реляционной БД использует LINQ.

А>>Я еще раз подчеркну, что я не сторонник хранения БЛ в процедурах. И тоже считаю, что расходы на создание объектов мизерны. Но вот пишут приложения на хранимках и TS.
C>Кто "пишут"? Поимённо, пожалуйста.

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

Банки, биллинговые системы операторов связи.....

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

G>>Смотря какие процедуры, многие ORM вполне спокойно мапят CRUD для сущностей на процедуры.
А>Ты не ответил на вопрос, что будет в коде, если весь БЛ в процедурах.
ответил: "что угодно". я видел реализацию active record, где все было на процедурах.

G>>Возможно, но я так не пишу. И не знаю никого кто так пишет.
А>Я тебя удивлю, но очень многие.
Значит мне повезло, я с такими не знаком.

А>>>Я не агитирую за такой подход, но большинство web приложений и приложений работающих под большой нагрузкой (сотни транзакций в секунду) работают именно на TS.
G>>stackoverflow работает под большой нагрузкой, но использует Linq2SQL
G>>То что ты пишешь было правдой 15 лет назад.
А>Посмотри на http://ormeter.net/ и увидишь разницу в материализации с ORM и без.
А что это должно показать?

http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html
Это мнение человека, который создал этот самый stackoverflow. Причем посмотри на дату, будешь удивлен.
Сейчас затраты на материализацию объектов из базы настолько малы, что всем пофиг.

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

G>>Убираем лишний уровень косвенности
G>>

G>>class Cotroller
G>>{
G>>    void SomeAction()
G>>    {
G>>        var o = repo.Get(id);
G>>        validationService.SomeValidation(o);
G>>        bllService.SomeLogic(o);
G>>        repo.Save(o);
G>>    }
G>>}
G>>

G>>После этого оптимизируем запросы, чтобы не поднимать целые объекты из базы, а только необходимое.
G>>Для целей реюза кода делаем extract method, сходные методы группируем в классы. Получили anemic.
А>Еще пару взмахов кисти: убираем все в хранимку, вместо сущностей используем ViewModel и вот он TS.

И снова вспоминаем про меняющиеся бизнес-правила валидации. С реализацией в коде я без проблем с помощью IoC-контейнера будут подсовывать правила в сервис валидации. А что делать в хранимке? Править её каждый раз... нет уж, спасибо.

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

C>>Хренимые процедуры сейчас явно уходят в legacy. Из топовых высоконагруженных сайтов архитектуру на хренимках вообще никто не строит (там вообще всё больше NoSQL). Даже Stackoverflow с классической реляционной БД использует LINQ.
А>Банки, биллинговые системы операторов связи.....
Ну оно и есть — legacy. Т.е. системы, которые развиваются часто ещё с 90-х годов.

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

AJD>>В анемике я бы сделал иерархию валидаторов.
А>Поведение объекта обычно не заканчивается валидацией, и почти на каждое(считай метод или логическую группу методов) тебе придется писать иерархию.
А>Выход, но наверно не очень.

Гораздо более плохой выход из ситуации множество иерархий объеденить в одну иерархию бизнес-объектов. Будет большущее нарушение SRP придется очень часто наследоваться или править классы.

G>Гораздо более плохой выход из ситуации множество иерархий объеденить в одну иерархию бизнес-объектов. Будет большущее нарушение SRP придется очень часто наследоваться или править классы.
Давайте на примере. Условия таковы: заказ может быть оплачен только, если он одобрен менеджером, отгружен если оплачен и одобрен.
Rich:
class Order
{
bool _isApproved;
bool IsPayed{get;set;}

bool CanApprove
{
get
{
return !IsPayed;
}
}

public void Approve()
{
if(!CanApprove)
{
throw ex.
}
_isApproved=true;
}

public bool CanPay
{
get
{
return !IsPayed && _isApproved;
}
}

public void Pay()
{
if(!CanPay())
{
// throw Ex
}
//что-то делаем
IsPayed=true;
}

public CanShip
{
get
{
return IsPayed && _isApproved;
}
}
}

DВ анемике, ты все равно создашь методы для проверки, + если добавится иерархия заказов в rich просто переопределяется поведение, в анемике ты все равно создашь иерархию классов, и как пишешь
G> Гораздо более плохой выход из ситуации множество иерархий объеденить в одну иерархию бизнес-объектов.
создашь 2 параллельных иерархии зависимых друг от друга.
В этом примитивном примере можно конечно все сделать "красиво" и в анемике, но жизнь сложна. Скорее всего для каких-то заказов, возможно для определенных клиентов можно отгружать и не оплаченные заказы. Потребители твоих объектов (доменные сервисы) ни когда об этом не узнают. А вот в анемике начинаются инжектирования, появляются ветвления для одного атрибута(состояния) в разных методах и т.д. В результате ты создаешь намного больше кода, логика разбросана по куче классов и как результат нет гарантии, что в методе сервиса не забудут добавить поведение.

C>Ну оно и есть — legacy. Т.е. системы, которые развиваются часто ещё с 90-х годов.
Да, но я видел несколько довольно крупных legacy проектов, которые переводили на процедуры в наше время.
И эти проекты были не форумами/блогами как Stackoverflow, БЛ там намного больше.

Давайте подведем черту:
1. Я не агетирую за испльзование хранимок и логики в базе.
2. Очень много систем с БЛ в хранимках, со слоем Application Services который отдает не сущности домена, а ViewModel/DTO специально созданные под View, т.е. в таких системах отсутствие модель как таковая. И как такие системы называть Domain Model или TS? Если DM тогда объясните почему ее так зовут.
п.2 я написал не из любви к таким системам, их очент не просто сопровождать, особенно когда несколько баз, процедур в каждой сотни. Это почти Ад.
Я хочу лишь сказать, что TS существует и занимает довольно значительную долю.
3. А вот что выбрать Rich или Anemic это уже может зависить от сложности БЛ, опыта и т.д..... У обоих подходов есть и плюсы и минусы. Но анемик находится где-то между Rich и TS. Те же процедуры но уже в коде сервисов. Это все таки процедурный подход. Мне больше нравится Rich, я согласен что он сложнее для написания,но не сопровождения, и немного уступает в производительности особенно кода нужно получить список ассоциаций для объекта (в Rich это LazyLoad, а в анемике можно написать getItemsForCondition(int orderID, ... что-то, можно даже пэйджинг прикрутить)).

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

G>>Гораздо более плохой выход из ситуации множество иерархий объеденить в одну иерархию бизнес-объектов. Будет большущее нарушение SRP придется очень часто наследоваться или править классы.
А>Давайте на примере. Условия таковы: заказ может быть оплачен только, если он одобрен менеджером, отгружен если оплачен и одобрен.
А>Rich:

А>class Order
А>{
А>  bool _isApproved;
А>  bool IsPayed{get;set;}
 
А>  bool CanApprove
А>  {
А>     get
А>     {
А>       return !IsPayed;
А>      }
А>  }

А>  public void Approve()
А>  {     
А>     if(!CanApprove)
А>      {
А>        throw ex.
А>      }
А>     _isApproved=true;
А>  }

А>  public bool CanPay
А>  {
А>    get
А>    {
А>       return !IsPayed && _isApproved;
А>     }
А>  }

А>   public void Pay()
А>   {
А>    if(!CanPay())
А>    {
А>    // throw Ex
А>    }
А>    //что-то делаем
А>    IsPayed=true;
А>   }

А>   public CanShip
А>   {
А>      get
А>      {
А>         return IsPayed && _isApproved;
А>      }
А>   }
А>}

Говнокод детектед. Как отобразить готовые к отгрузке заказы или ожидающие утверждения? Икапсуляция резко идет лесом.

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



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

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

А>В этом примитивном примере можно конечно все сделать "красиво" и в анемике, но жизнь сложна.
То что сложно делается в anemic в rich получается еще сложнее. Обратных примеров я покачто не видел.

А>Скорее всего для каких-то заказов, возможно для определенных клиентов можно отгружать и не оплаченные заказы. Потребители твоих объектов (доменные сервисы) ни когда об этом не узнают. А вот в анемике начинаются инжектирования, появляются ветвления для одного атрибута(состояния) в разных методах и т.д. В результате ты создаешь намного больше кода, логика разбросана по куче классов и как результат нет гарантии, что в методе сервиса не забудут добавить поведение.

Ты правда считаешь что один-два if создает больше кода, чем наследование класса + переопределение методов + настройка маппинга для создание объекта нужного класса + создание параллельной иерархии для валидаторов или ещечегонить?

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

А>Давайте подведем черту:
А>1. Я не агетирую за испльзование хранимок и логики в базе.
Тогда к чему были посты?

А>2. Очень много систем с БЛ в хранимках, со слоем Application Services который отдает не сущности домена, а ViewModel/DTO специально созданные под View, т.е. в таких системах отсутствие модель как таковая.
Это сильно устаревшие системы. Многие из них зародились до 2000 года. Сейчас использовать ХП — анахронизм.

А>И как такие системы называть Domain Model или TS? Если DM тогда объясните почему ее так зовут.
Как хочешь, так и называй, мне то что?
90% ХП, которые я видел — обычный CRUD и прекрасно мапятся с помощью ORM, а там хоть DM, хоть acive record.

А>Я хочу лишь сказать, что TS существует и занимает довольно значительную долю.
TS в каком виде? Как фаулер описал? Я такого вообще нигде не видел.
Если называть TS когда хранимки вызываются из button_click, то возможно ты и прав.

А>3. А вот что выбрать Rich или Anemic это уже может зависить от сложности БЛ, опыта и т.д..... У обоих подходов есть и плюсы и минусы.
У Rich скорее минусы, чем полюсы.

А>Но анемик находится где-то между Rich и TS.
По какой шкале? Какое отношение порядка ты используешь?

А>Те же процедуры но уже в коде сервисов.
Вообще-то нет, современные языки гораздо богаче диалектов SQL.

А>Это все таки процедурный подход.
Я бы сказал "функциональный", ибо не используя композицию функций не добиться положительных результатов.

А>Мне больше нравится Rich, я согласен что он сложнее для написания,но не сопровождения, и немного уступает в производительности особенно кода нужно получить список ассоциаций для объекта (в Rich это LazyLoad, а в анемике можно написать getItemsForCondition(int orderID, ... что-то, можно даже пэйджинг прикрутить)).
Самая большая проблема rich, что его недостатки не лечатся вообще никак. Если пытаться избавиться от недостатков, то получается anemic. Собственно я и говорил что хороший rich — это anemic. Даже тебе показал преобразование, которое дает решению большую гибкость и простор для оптимизации.

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

C>>Ну оно и есть — legacy. Т.е. системы, которые развиваются часто ещё с 90-х годов.
А>Да, но я видел несколько довольно крупных legacy проектов, которые переводили на процедуры в наше время.
А>И эти проекты были не форумами/блогами как Stackoverflow, БЛ там намного больше.

Думаешь в stackoverflow мало бл? Сильно ты заблуждаешься. Только stackoverflow держит бешеные нагрузки, а этот "legacy софт на ХП" падает при смешном количестве пользователей.

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

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

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


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

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

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

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

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

G>Думаешь в stackoverflow мало бл? Сильно ты заблуждаешься. Только stackoverflow держит бешеные нагрузки, а этот "legacy софт на ХП" падает при смешном количестве пользователей.

Все сильно зависит от типа нагрузки. Очень сильно сомневаюсь, что у stackoverflow на каждый чих производится транзакционная вставка и обновление кучи таблиц, как это происходит в банковском софте.

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

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

G>>Думаешь в stackoverflow мало бл? Сильно ты заблуждаешься. Только stackoverflow держит бешеные нагрузки, а этот "legacy софт на ХП" падает при смешном количестве пользователей.

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

Может и не на каждый чих, но у stakoverflow почти каждую секунду появляются вопросы\ответы и оценки, а если весь stakexchange рассмотреть, то там гораздо больше выйдет. некоторый "Банковский софт" умудряется тормозить при совершенно банальных операциях, вроде просмотра форм, двумя-тремя пользователями раз в минуту.

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

А>Здравствуйте, 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 и с синхронным сохранением в базу — хранимки выгоднее. Слишком накладно несколько раз ходить в базу.

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