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

T>Я не про это. Сколько надо update statements, чтобы изменить разом несколько свойств пользователя? Или как будет выглядеть запрос поиска пользователя, имеющего заданные свойства, например, имя, фамилию, телефон.

При таком подходе обычно UPDATE, заменяется на INSERT или DELETE+INSERT. Количество запросов порядка количества изменившихся полей. Для того же User при изменении фамилии можно писать только фамилию и не городить для этого отдельный запрос. Для объектов изменяющихся полностью выгоды никакой, сплошные убытки. Эффективно искать тоже не выйдет. Хотя и со столбцами эффективно искать не выйдет, на все столбцы индексы не повесишь.

Я вообще это всё предлагал как пример схемы БД поддерживающей некоторые расширения бизнес-логики без переделки схемы БД, а не как универсальное средство. Критика верная, но не совсем в кассу.

T>А что синтаксис хранимок oracle и mssql настолько одинаков?

Синтаксис вызова хранимок из ADO достаточно одинаков. А при переезде с Oracle на MSSQL и так придётся много чего переписать.

T>Кроме того, как реализовать запросы с переменным кол-вом параметров через ХП?

Это зачем тебе такое на уровне БД? Мне приходит в голову только поиск, но если мы говорим о чётком поиске (user по id) то никакого переменного числа параметров нет, а если о нечётком (помню 3ю буква в фамилии и 5ую в имени), то это не для уровня БД задача.

T>Когда-нибудь у меня дойдут руки написать небольшой тестик и сравнить скорость выполнения бизнес-логики в ХП и скажем в C или Java.

Никто бизнес-логику в ХП переносить и не предлагал.

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

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

С>10000 строк кода? Да это не много. Ну в том смысле, что 10000 строк можно полностью перелопатить и не трястись от страха, что что-то забыл.

Да уж. Помню в небольшом проектике где таблиц 40 было, DAO класс (он был почему то один) было больше 5000 строк.
Правда там был низкоуровневый JDBC

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

IT>>И в чём проблема добавить ещё одно поле в таблицу?

A>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.

И Вы все еще рекомендуете использовать ХП вместо ORM?

Ежики плакали, но продолжали жрать кактус.

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


K>основано на материалах martinfowler.com

K>критикуйте

В целом хороший ответ, только Вас сейчас закидают гнилыми помидорами за применение синглтона.

Очень рекомендую Castle Windsor (или MicroKernel) для уменьшения зависимостей.

http://www.castleproject.org/container/index.html

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

A>>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.
kuj>И Вы все еще рекомендуете использовать ХП вместо ORM?

Коррекция SQL запросов по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
У ХП совсем другие преимущества, я их уже указывал. Быть слепым личное дело каждого.

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

IT>1. View можно джоинить с другими таблицами.
IT>2. ХП не имеет формальной структуры результата.

Я вообще-то про поддержку спрашивал, а не про использование.

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


A>>>Проблема существенная. Во-первых, это добавление цепной реакцией прокатывается по всем SQL запросам. Во-вторых, столбец надо добавить во множестве мест, то есть приходиться делать уже не просто инсталляции, а апдейтеры зовущие ALTER TABLE и тестировать не только инсталляцию продукта, но и апдейтеры на всех комбинациях версий продукта. Это нелинейно увеличивает объём тестирования.
kuj>>И Вы все еще рекомендуете использовать ХП вместо ORM?

A>Коррекция SQL запросов
При чем тут запросы, если речь о процедурах. Вы, конечно же, ничего не знаете о синтаксисе того же PL/SQL и как значительно он отличается от T-SQL? PL/SQL значительно мощнее T-SQL, поэтому "downgrade" на T-SQL зачастую задача далеко не тривиальная.

A>по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
Плохому танцору яйца мешают.

A>У ХП совсем другие преимущества, я их уже указывал.
Где?
тезис 1: хп хорошо потому, что "использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными" — false
тезис 2: хп хорошо потому, что "ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения." — запросы в транзакции и с использованием ORM объединяются прекрасно и ORM дают даже более мощную функциональность по управлению транзакциями — false
тезис 3: хп хорошо потому, что "ХП напротив проще поддерживать" — нетестируемые, нечитабельные, почти не поддающиеся рефакторингу, куда более сильно привязанные к СУБД и конкретной схеме — false

A>Быть слепым личное дело каждого.
Совершенно верно. Быть слепым это Ваше личное дело. Только не надо пытаться навязывать другим плоды своего ограниченного мышление, не обремененного знаниями современных технологий в области архитектуры enterprise-приложений и БД.

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

A>>Коррекция SQL запросов
kuj>При чем тут запросы, если речь о процедурах. Вы, конечно же, ничего не знаете о синтаксисе того же PL/SQL и как значительно он отличается от T-SQL? PL/SQL значительно мощнее T-SQL, поэтому "downgrade" на T-SQL зачастую задача далеко не тривиальная.

Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?

A>>по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
kuj>Плохому танцору яйца мешают.

Ещё один мегагениальный комментарий от человека который никогда не занимался поддержкой инсталляций.

kuj>тезис 1: хп хорошо потому, что "использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными" — false

true. И Синклер тебе даже дал ссылку на инструментарий.

kuj>тезис 2: хп хорошо потому, что "ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения." — запросы в транзакции и с использованием ORM объединяются прекрасно и ORM дают даже более мощную функциональность по управлению транзакциями — false

Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.

kuj>тезис 3: хп хорошо потому, что "ХП напротив проще поддерживать" — нетестируемые, нечитабельные, почти не поддающиеся рефакторингу, куда более сильно привязанные к СУБД и конкретной схеме — false

Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.

kuj>Совершенно верно. Быть слепым это Ваше личное дело. Только не надо пытаться навязывать другим плоды своего ограниченного мышление, не обремененного знаниями современных технологий в области архитектуры enterprise-приложений и БД.

У меня по крайне мере есть мышление, а твои сообщения либо бессмысленны, либо противоречивы.

Здравствуйте, Cyberax, Вы писали:
C>А если механически разбить все эти GetUsersByBlah на несколько сервисов?
А смысл?

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

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

S>>Идея правильна, в реализации не уверен.
S>>Я имел опыт с системами, построенными подобным образом. Традиционно считается, что схему данных менять тяжелее, чем сами данные.
S>>Однако это далеко не всегда так; кроме того, "добавление колонок" далеко не всегда сводится только к полям в UI. Как только начнет появляться какая-то бизнес-логика вокруг этих полей, например foreign key или запросы по их содержимому, начинаются проблемы. Как на уровне БД так и на уровне маппинга. По сравнению с этими трудностями alter table add column покажется детским лепетом.

A>Ну вообще-то из примера вроде было видно, что группируются таким образом только то, над чем проводятся однотипные операции. Login и Password я не вынес. Во-первых, это ударит по производительности, во-вторых, с ними проводится совсем другой набор операций.
Я это веду к тому, что раз уж такие "резиновые" поля так отличаются от "основных", то может иметь смысл отразить это и на уровне апп.сервера. Т.е. так и добавить в Person свойство CustomProperties типа Dictionary<string, object>. Тогда добавление нового свойста не затронет не только БД, но даже и код перекомпилировать не придется!

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

S>Здравствуйте, Cyberax, Вы писали:
C>>А если механически разбить все эти GetUsersByBlah на несколько сервисов?
S>А смысл?
Просто сгруппировать по определенным признакам, для удобства редактирования. Нет ничего плохого в разрастании количества DAO-методов — это просто значит, что у вас много логики.

Здравствуйте, Cyberax, Вы писали:
C>Просто сгруппировать по определенным признакам, для удобства редактирования.
Для удобства редактирования чего?
C>Нет ничего плохого в разрастании количества DAO-методов — это просто значит, что у вас много логики.
Имхо, это иллюзия. Я наглядно вижу разрастание количества DAO методов на пустом месте, и неэффективное использование как ресурсов сервера, так и канала при передаче избыточных данных.

Я бы хотел избежать необходимости менять публичный контракт сервиса всякий раз, как один из клиентов немножко переделает UI.

C update-методами есть другая аналогичная проблема: поскольку нет способа объединить несколько методов в транзакцию, то нам приходится публиковать методы для различных популярных комбинаций.
Например, есть методы CreateUser, CreateSite, AssignSiteToUser. Эти методы нужны, т.к. вызываются в некоторых бизнес-сценариях. Теперь обнаруживается сценарий, при котором нужно сразу создать пользователя, сайт, и присвоить сайт пользователю. Проблема в том, что если какое-то из действий не пройдет, то нужно откатывать всё. Конечно, можно сделать с клиента цепочку try с обратными действиями в catch:

user=CreateUser(...);
try
{
  site = CreateSite(...);
    try
    {
      AssignSiteToUser(site, user);
    }
    catch
    {
      DeleteSite(site);
        throw;
    }
}
catch
{
  DeleteUser();
    throw;
}

Но это-ненадежная схема, т.к. если в процессе порвется коннект, то Delete*() вызвать не удастся у нас так и останется мусор в сервере.
Поэтому мы делаем метод CreateUserWithSite с совершенно тривиальной реализацией.


В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP. Потому, что там ни одной из этих проблем нет: мы можем указывать произвольные предикаты для отбора и сортировки записей, а не только те, которые предусмотрел разработчик БД; мы можем запрашивать только те поля, которые нам нужны; мы можем управлять атомарностью действий, оборачивая батч в явную транзакцию.

у SQL, конечно же, есть свои недостатки. Но, имхо, невредно было бы придумать схему с преимуществами обоих подходов.

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

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

A>>>>Плюс коллекции хибернета нарушают PI.
kuj>>>Не совсем понял. Разъясните пожалуйста.

A>>Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, NHibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the discussion of bidirectional associations later in this chapter.
A>>

A>>Вынуждены использовать коллекции хибернета вместо стандартных.

kuj>Э-э, а чем это мешает BLL? Ведь работаем-то все-равно через интерфейсы (IList, ICollections, etc). Или Вы не об этом, говоря, что нарушается PI?
Вынуждены использовать конкретную реализацию коллекции, навязанную персистентным слоем, вместо того, что бы выбирать реализацию в соответсвии с требованиями BL.

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

C>>Нет ничего плохого в разрастании количества DAO-методов — это просто значит, что у вас много логики.
S>Имхо, это иллюзия. Я наглядно вижу разрастание количества DAO методов на пустом месте, и неэффективное использование как ресурсов сервера, так и канала при передаче избыточных данных.
S>Я бы хотел избежать необходимости менять публичный контракт сервиса всякий раз, как один из клиентов немножко переделает UI.
У меня DAO-аксессоры находятся в статических методах helper-классов. Так что никаких проблем.

S>Например, есть методы CreateUser, CreateSite, AssignSiteToUser. Эти методы нужны, т.к. вызываются в некоторых бизнес-сценариях. Теперь обнаруживается сценарий, при котором нужно сразу создать пользователя, сайт, и присвоить сайт пользователю. Проблема в том, что если какое-то из действий не пройдет, то нужно откатывать всё. S>Поэтому мы делаем метод CreateUserWithSite с совершенно тривиальной реализацией.
Нда... Неудивительно тогда, что головой об стенку стучите.

Есть более надежное решение — явно передавать транзакционный контекст в DAO-методы. Например, у меня оно сделано так:

public class ShiftLocationHelper
{
   public List<Shift> getShiftsNearestToLocation(Session sess, Location loc)
   {
       return sess.createQuery("...").list();
   }
};

Сессия, которую я явно передаю в качестве параметра, связана с транзакционным контекстом. Если не хочется передавать транзакционный контекст явно — храните его во thread-local переменной (и ругайтесь в аксессорах, если нет текущего контекста).

Причем это все очень хорошо сочетается с AOP. Скажем, у меня транзакции управляются автомагически (использую Spring):

@Transactional(readOnly=true)
public class SomeService
{
    //Будет "впрыснута" контейнером, с автоматическим распространением транзакционного контекста.
    private Session session;

    public void doSomething()
    {
        //Здесь у нас _обязательно_ будет транзакционный контекст.
    }
    
    @Transactional(propagation=REQUIRES_NEW)
    public void doSomethingBad()
    {
        //Здесь у нас тоже будет транзакция, но она будет создана при входе в 
        //метод и закоммичена/откачена при выходе из метода. На длительность метода
        //предыдущая транзакция (если она есть) приостанавливается.
    }
    //И т.п. Еще есть Supports/Never/Nested/...
}
//XML-файл с настройками пропускаю.

//Используем примерно так:
UserTransactionManager utm=(UserTransactionManager)factory.getBean("userTransactionManager");
SomeService src=(SomeService)factory.getBean("someServiceName");

//Это совсем ручное управление транзакциями - обычно его можно тоже автоматизировать.
utm.begin();
try
{
  src.doSomething(param1);
  src.doSomething(param2);
  utm.commit();
} catch(Throwable t)
{
  utm.rollback();
}

В результате, использовать такое ОЧЕНЬ удобно. Про проблемы с транзакциями я даже уже и думать забыл.

S>В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP.
SOAP — это вообще маразм. Он сейчас повторяет всю историю CORBA.

S>Потому, что там ни одной из этих проблем нет: мы можем указывать произвольные предикаты для отбора и сортировки записей, а не только те, которые предусмотрел разработчик БД; мы можем запрашивать только те поля, которые нам нужны; мы можем управлять атомарностью действий, оборачивая батч в явную транзакцию.
S>у SQL, конечно же, есть свои недостатки. Но, имхо, невредно было бы придумать схему с преимуществами обоих подходов.
Может вам стоит на Spring+Hibernate в Java посмотреть? Там множество этих проблем уже решено.

Вообще, я давно уже хочу нашу внутреннюю документацию по серверу приложений в нормальный вид привести и в виде статьи выложить. Всё руки не доходят...

Здравствуйте, Cyberax, Вы писали:
S>>Я бы хотел избежать необходимости менять публичный контракт сервиса всякий раз, как один из клиентов немножко переделает UI.
C>У меня DAO-аксессоры находятся в статических методах helper-классов. Так что никаких проблем.
И что? Я не понимаю, как расположение DAO-аксессоров может помочь с сокращением dummy изменений в зависимости от пожеланий клиента.

C>Нда... Неудивительно тогда, что головой об стенку стучите.
C>Есть более надежное решение — явно передавать транзакционный контекст в DAO-методы. Например, у меня оно сделано так:
Через границу сервиса транзакционный контекст передавать нельзя. Потому, что тогда нарушится Statelessness.
S>>В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP.
C>SOAP — это вообще маразм. Он сейчас повторяет всю историю CORBA.
Альтернативы? REST?
C>Может вам стоит на Spring+Hibernate в Java посмотреть? Там множество этих проблем уже решено.
Очень я в этом сомневаюсь. Внутре апп-сервера всё и так более-менее прилично; даже BLT уже позволяет минимизировать лишний код.
Но как только мы пытаемся сделать платформенно-независимый public API, начинаются какие-то чудеса.
Мысли некоторые у меня по этому поводу есть, но пока что до реализации им, мягко говоря, далеко.

C>Вообще, я давно уже хочу нашу внутреннюю документацию по серверу приложений в нормальный вид привести и в виде статьи выложить. Всё руки не доходят...

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

C>>Нда... Неудивительно тогда, что головой об стенку стучите.
C>>Есть более надежное решение — явно передавать транзакционный контекст в DAO-методы. Например, у меня оно сделано так:
S>Через границу сервиса транзакционный контекст передавать нельзя. Потому, что тогда нарушится Statelessness.
Так решите что вам важнее — удобное управление транзакциями или statelessness. Тут одно из двух. Кстати, если напрямую использовать SQL — то это тоже уже stateful-соединения.

Кстати, еще возможное решение — отсылать на сервер блоки кода для выполнения. В Java для этого тоже есть библиотеки

S>>>В итоге, я начинаю думать, что SQL — значительно более хороший протокол клиент-серверного взаимодействия, чем, к примеру, SOAP.
C>>SOAP — это вообще маразм. Он сейчас повторяет всю историю CORBA.
S>Альтернативы? REST?
Старый добрый RPC через какой-нибудь протокол — если нужна распределенная работа. Ну и первое правило распределенного программирования — "do not distribute".

C>>Может вам стоит на Spring+Hibernate в Java посмотреть? Там множество этих проблем уже решено.
S>Очень я в этом сомневаюсь. Внутре апп-сервера всё и так более-менее прилично; даже BLT уже позволяет минимизировать лишний код.
S>Но как только мы пытаемся сделать платформенно-независимый public API, начинаются какие-то чудеса.
S>Мысли некоторые у меня по этому поводу есть, но пока что до реализации им, мягко говоря, далеко.
У меня была та же проблема — связать друг с другом две системы, с сохранением транзакций. Делал исследование на эту тему — ничего нормального для этого нет. Есть WS-AtomicTransaction, и даже поддерживается MS и другими вендорами. Только вот на практике все получается черезчур монструозно.

В результате остановились на работе через общую базу данных и общение через транзакционный JMS (Java Messaging System).

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

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


K>>основано на материалах martinfowler.com

K>>критикуйте

kuj>В целом хороший ответ
Спосибо
kuj>, только Вас сейчас закидают гнилыми помидорами за применение синглтона.

а я так для упрощения написал.
вот комЕнт с отмазкой:

// Service Locator, для той же цели можно использовать какойнибудь контейнер

даже не "можно", а "лучше"

kuj>Очень рекомендую Castle Windsor (или MicroKernel) для уменьшения зависимостей.

kuj>http://www.castleproject.org/container/index.html
еще слыхал про NanoContainer (или PicoContainer),
в MS CAB используется свой ObjectBuilder.
но видимо Windsor проще

помойму вообще лучше всего делать на каком-нить каркасе, типа Spring или Eclipse RCP., там и сразу контейнер интегрирован, и большая часть работы сделана

Здравствуйте, Cyberax, Вы писали:
C>Так решите что вам важнее — удобное управление транзакциями или statelessness. Тут одно из двух.
Ничего подобного. Удобное управление транзакциями — это возможность отправить батч.
Опасно только удержание транзакции с клиентской стороны.

C> Кстати, если напрямую использовать SQL — то это тоже уже stateful-соединения.
Это если пользоваться им неаккуратно.

C>Кстати, еще возможное решение — отсылать на сервер блоки кода для выполнения.
Именно об этом я и думаю.

C>В Java для этого тоже есть библиотеки
И как их вызывать из Classic ASP или Perl?

C>Старый добрый RPC через какой-нибудь протокол — если нужна распределенная работа. Ну и первое правило распределенного программирования — "do not distribute".
А RPC-то чем поможет??? Он точно так же жестко типизирован. Отличие SOAP — только в канале.

C>У меня была та же проблема — связать друг с другом две системы, с сохранением транзакций. Делал исследование на эту тему — ничего нормального для этого нет. Есть WS-AtomicTransaction, и даже поддерживается MS и другими вендорами. Только вот на практике все получается черезчур монструозно.
Вот-вот, я о том же.
C>В результате остановились на работе через общую базу данных и общение через транзакционный JMS (Java Messaging System).

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

C>>Так решите что вам важнее — удобное управление транзакциями или statelessness. Тут одно из двух.
S>Ничего подобного. Удобное управление транзакциями — это возможность отправить батч.
S>Опасно только удержание транзакции с клиентской стороны.
Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут. Всякие гадости типа исчерпания пулов из-за глючных клиентов — тоже можно при желании обрабатывать.

C>> Кстати, если напрямую использовать SQL — то это тоже уже stateful-соединения.
S>Это если пользоваться им неаккуратно.
В любом случае. SQL-соединение по своей сути имеет состояние, да хотя бы транзакционный контекст (если только не ставить автокоммит, конечно).

C>>В Java для этого тоже есть библиотеки
S>И как их вызывать из Classic ASP или Perl?
Отсылать куски скрипта на каком-нибудь языке? На сервере — посадить этот скрипт в домен с максимально обрезаными правами.

Есть, конечно, еще BPEL. Но я бы его не трогал без крайней надобности.

C>>Старый добрый RPC через какой-нибудь протокол — если нужна распределенная работа. Ну и первое правило распределенного программирования — "do not distribute".
S>А RPC-то чем поможет??? Он точно так же жестко типизирован. Отличие SOAP — только в канале.
SOAP подразумевает передачу документов и их обработку сервисами. В случае с RPC мы обычно передаем проксики для объектов на сервере и работаем с ними на клиенте. То есть, можно организовать stateful-операции сравнительно малой кровью.

Здравствуйте, Cyberax, Вы писали:
C>Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут.
Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
C>Всякие гадости типа исчерпания пулов из-за глючных клиентов — тоже можно при желании обрабатывать.
То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
C>В любом случае. SQL-соединение по своей сути имеет состояние, да хотя бы транзакционный контекст (если только не ставить автокоммит, конечно).
Это в общем случае.
В частном случае вменяемого разработчика в SQL отъезжают только атомарные батчи:

begin tran 
--do smth
--do smth else
commit tran

Никаких открытых транзакций оставаться не должно.
C>Отсылать куски скрипта на каком-нибудь языке? На сервере — посадить этот скрипт в домен с максимально обрезаными правами.
Да. Для удобства этот язык можно назвать Structured Query Language.
C>SOAP подразумевает передачу документов и их обработку сервисами. В случае с RPC мы обычно передаем проксики для объектов на сервере и работаем с ними на клиенте. То есть, можно организовать stateful-операции сравнительно малой кровью.
Не, "stateful" и "малой кровью" — вещи несовместимые. Задача как раз избавиться от state, т.к. он очень плохо масштабируется (про коммерческие распределенные кэши я в курсе).