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

O>>>DataSet то же не хотелось бы, не то, чтобы я сильно религиозен, но мозги придется перекраивать сновательно.
MC>>В принципе датасеты вариант, но лично мне кажется что они провоцируют дублирование логики, а так же вынос логики в presentation. К тому же нетипизированные датасеты неудобны отсутствием типизации, а типизированные датасеты дают мало контроля, т.к. все генерируется и перегенерируется автоматически.
O> Вот вот, поэтому и не хочу с ними связываться.
Кстати для опыта можно и что-нибудь сделать с ними, выявите для себя удобства и недостатки.

MC>>Ну это зависит от задачи. Если мы принимаем 10 заказов от разных клиентов (через веб-сервис к примеру) и принялись только 5, после чего возникла ошибка — то откатывать все не нужно, просто запросить те которые не принялись и попытаться их сохранить. Если же действия должны быть "атомарными", то да, откатываем все 10. Но видимо у нас с вами тут какое-то недопонимание, потому как я не понимаю, почему пользователю придется переделывать все 10? К примеру пользователь открывает форму с разными полями для редактирования и гридом, что-то там изменяет и жмет сохранить. Если где-то косяк (к примеру ошибка валидации или ваша любимая коллизия), то пользователю просто сообщится о конкретной ошибке ("Product price can not exceed $100000"), на форме же останутся изменения сделанные пользователем. Пользователь исправляет что нужно и жмет Сохранить еще раз.
O> Хороший варант, только усложняет обработку ошибок, хотя может и не так сильно как мне кажется. Спасибо.
Чем усложняет? Можно подробнее?

O> Вот это мне и не нравится, ибо сложности предметной области в данном случае могут вылиться в большой объем логики обработки таких ошибок. Подозреваю, что проще лочить объекты перед началом редактирования.
Не знаю, я не специалист в этой теме. Давайте лучше не будем говорить абстрактно, а рассмотрим пару примеров. Приведите пару конкретных реальных примеров из вашей задачи, и думаю что знающие люди предложат решения для этих конкретных случаев. Думаю что так от беседы будет больше практической пользы.

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

MC>>>Ну это зависит от задачи. Если мы принимаем 10 заказов от разных клиентов (через веб-сервис к примеру) и принялись только 5, после чего возникла ошибка — то откатывать все не нужно, просто запросить те которые не принялись и попытаться их сохранить. Если же действия должны быть "атомарными", то да, откатываем все 10. Но видимо у нас с вами тут какое-то недопонимание, потому как я не понимаю, почему пользователю придется переделывать все 10? К примеру пользователь открывает форму с разными полями для редактирования и гридом, что-то там изменяет и жмет сохранить. Если где-то косяк (к примеру ошибка валидации или ваша любимая коллизия), то пользователю просто сообщится о конкретной ошибке ("Product price can not exceed $100000"), на форме же останутся изменения сделанные пользователем. Пользователь исправляет что нужно и жмет Сохранить еще раз.
O>> Хороший варант, только усложняет обработку ошибок, хотя может и не так сильно как мне кажется. Спасибо.
MC>Чем усложняет? Можно подробнее?

В случае оптимистических блокировок (разруливание по факту обновления, а не перед) модет оказаться необходимым выяснять зависимости меду объектами, чтобы делать мержи, откаты или накаты, это будет зависеть от предметной области, которая может быть доволно сложной.

O>> Вот это мне и не нравится, ибо сложности предметной области в данном случае могут вылиться в большой объем логики обработки таких ошибок. Подозреваю, что проще лочить объекты перед началом редактирования.
MC>Не знаю, я не специалист в этой теме. Давайте лучше не будем говорить абстрактно, а рассмотрим пару примеров. Приведите пару конкретных реальных примеров из вашей задачи, и думаю что знающие люди предложат решения для этих конкретных случаев. Думаю что так от беседы будет больше практической пользы.

Ну вот, допустим выгружается на клиента список клиентов и их счета и договора. Информация о клиенте исправляется и отправляется на сервер (можно уже сказать, что это будет непосредственно БД) для апдейта. Сервер кидает исключение, что не может проапдейтить определенного клиента. Вот тут и придется, в соответствии с конкретным объектом и его состоянием принимать решение либо о мерже либо об откате либо о накате. очевидно, что логика предметной области в такой момент может сильно раздутьв в реализации. Видимо, это устраняется пессимистичной блокировкой, когда клиент и его зависимости лочаться перед редактированием.

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

O> Ну вот, допустим выгружается на клиента список клиентов и их счета и договора. Информация о клиенте исправляется и отправляется на сервер (можно уже сказать, что это будет непосредственно БД) для апдейта. Сервер кидает исключение, что не может проапдейтить определенного клиента. Вот тут и придется, в соответствии с конкретным объектом и его состоянием принимать решение либо о мерже либо об откате либо о накате. очевидно, что логика предметной области в такой момент может сильно раздутьв в реализации. Видимо, это устраняется пессимистичной блокировкой, когда клиент и его зависимости лочаться перед редактированием.

Чем этот пример отличается от простого редактирования клиентов без счетов и договоров (это я чтобы избавить пример от возможно ненужных зависимостей)?

Как вы сами считаете должна вести себя система если при сохранении клиента оказывается что в БД уже есть более новая версия клиента?
Или вы считаете что нельзя редактировать клиента одновременно на разных машинах? Если нельзя редактировать клиента на разных машинах, то когда ставить блокировку? И что если оператор уйдет на обед?

Т.е. сначала надо определиться с этими вопросами. Может кто из более опытных участников посоветует наиболее подходящие решения для таких сценариев.

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

O>> Ну вот, допустим выгружается на клиента список клиентов и их счета и договора. Информация о клиенте исправляется и отправляется на сервер (можно уже сказать, что это будет непосредственно БД) для апдейта. Сервер кидает исключение, что не может проапдейтить определенного клиента. Вот тут и придется, в соответствии с конкретным объектом и его состоянием принимать решение либо о мерже либо об откате либо о накате. очевидно, что логика предметной области в такой момент может сильно раздутьв в реализации. Видимо, это устраняется пессимистичной блокировкой, когда клиент и его зависимости лочаться перед редактированием.
MC>Чем этот пример отличается от простого редактирования клиентов без счетов и договоров (это я чтобы избавить пример от возможно ненужных зависимостей)?

В том то и дело, что записимости возможно нужны.

MC>Как вы сами считаете должна вести себя система если при сохранении клиента оказывается что в БД уже есть более новая версия клиента?

В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.

MC>Или вы считаете что нельзя редактировать клиента одновременно на разных машинах?

Наоборот, я только и делаю, что везде пишу про проблемы с этим связанные

MC>И что если оператор уйдет на обед?

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

MC>Т.е. сначала надо определиться с этими вопросами. Может кто из более опытных участников посоветует наиболее подходящие решения для таких сценариев.

Только на них и надеюсь

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

O> В том то и дело, что записимости возможно нужны.
Подробнее? Как они влияют на пример?

O> В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.
Мы сейчас конкретный пример пытаемся разобрать. Какие там обстоятельства? Вы опять от конкретного примера уходите в абстракцию.
Или можете ответить "я не знаю как лучше, подскажите"?

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

O> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>том же кэше говорим?

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

O> Пока всегда хватало сурогатного Int64.

Вам говорят о его генерации, identity это то, чего следует избегать. Используйте гуиды на худой конец, раз MSSQL не имеет нормального сиквенса.

Ziaw, а можно прокомментировать в чем вы так несогласны?

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

O>> В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.
MC>Мы сейчас конкретный пример пытаемся разобрать. Какие там обстоятельства? Вы опять от конкретного примера уходите в абстракцию.

Конкретная стратегия зависит именно от конкретного объекта который вызвал конфликт. От логики предметной области. Она должна диктовать что в данном случае следует сделать. Какая конкретика нужна еще? Как пользователю удобнее так и следует сделать, лишь бы логику не нарушить.

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

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

O>> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>>том же кэше говорим?

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

Товарищ Ziaw, не запутывайте ) "Их гораздо больше, чем 2" можно трактовать весьма по-разному
Уровней кеша в NHibernate 2 -- session object и 2nd level cache. Второй уровень -- реализован по типу plug-in: вы подставляете тот провайдер, который нужен. NativeHash, SysCache, SharedCache, Bamboo.Prevalence, memcached, NCache, OSCache -- это разнообразные провайдеры, выбирайте тот, который нужен, и вперед. Prevalence, например, умеет персиститься на диск, SharedCache -- реплицироваться между машинами, а NCache -- хороший, но его основные вкусности начинаются только в платной версии )

O>> Пока всегда хватало сурогатного Int64.
Z>Вам говорят о его генерации, identity это то, чего следует избегать. Используйте гуиды на худой конец, раз MSSQL не имеет нормального сиквенса.

Ой-ёй, только не guid =) Он слишком рандомный; это убивает индекс, и MS-SQL плохо на них реагирует (низкой производительностью). Лучше использовать HiLow или guid.comb, если уж очень хочется гуидов (в этом случае они ложатся компактным кластером).

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

M>Товарищ Ziaw, не запутывайте ) "Их гораздо больше, чем 2" можно трактовать весьма по-разному

Сорри ) Не совсем однозначно высказался. Следует читать — "разновиднойстей кеша 2го уровня для NH гораздо больше чем 2".

M>Ой-ёй, только не guid =) Он слишком рандомный; это убивает индекс, и MS-SQL плохо на них реагирует (низкой производительностью). Лучше использовать HiLow или guid.comb, если уж очень хочется гуидов (в этом случае они ложатся компактным кластером).

Интересно, а можно линк на эту тему?

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

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

O> Не понял, что подразумевается под генератором DTO. Пока решено гнять тонкие бизнес-объекты, а в тонких местах — DTO.
Если объекты таки будут толстыми, то писать для них вручную DTO и код Rich Object <-> DTO затруднительно. Otislib -- это object-2-object mapper, который позволяет задать, как трансформировать объекты один в другой, и не писать вручную код, который должен будет это делать.

O> Сейчас начинаю понимать, что наличие единого сервера не нужно, поэтому клиенты будут просто получать из БД (от NHibernate) бизнес объекты и лочить/апдейтить их самостоятельно, а не через сервер. Соответственно, необходимость в DTO отпадает, как я понимаю.
Хм, интересно, как вы в отсутствии единого сервера организуете общий кэш? У вас на каждом клиенте планируется иметь фабрику сессий NHibernate?

M>>3) Определиться с тем, как вы будете решать конфликты одновременного обновления: пессимистический вариант и оптимистический, соотственно.
M>>В случае пессимистического вы не допускаете конфликтов -- при помощи транзакций БД(хардкор, но иногда допустим=)) или на уровне бизнес-транзакций (т.н. conversation), помечая и блокируя бизнес-объекты , находящиеся в редактировании;
M>>В случае оптимистического варианта вы решаете разруливать конфликты одновременного обновления по факту обнаружения таких конфликтов. Вариантов здесь а)затирать старые изменения (игнорируем конфликт) б) не давать затирать при помощи проверки версии (NHibernate вам в помощь) и просить пользователя внести вторично правку в устаревшие данные в) реализовать стратегию merge данных, если данные могут быть объединены без логического конфликта
M>>Ничего не мешает сочетать эти варианты, согласуясь с другими критериями.

O> Да, решено уже по мере надобности сочетать разные блокировки. Пугает только, что это может вылиться в большой объем логики обработки исключений конфликтов.
Воспользуйтесь PostSharp для разделения логики обработки конфликтов и остальной логики. Я пользуюсь AOP из Spring.NET, но принцип тот же.

O> Я и сам догадываюсь, но все равно напишите, т.к. я не знаю как это выразить словами. То, что NHibernate поддерживает <version> я знал, но использовать не приходилось и смутно представляю реализацию в sql. Видимо при апдейте идет проверка, что свойство version = currentVersion.
Примерно так, как вы сказали. Если сконфигурирована проверка version (timestamp), то NHibernate при сохранении проверяет, что версия в БД -- та же, что и в объекте. Если сконфигурирована select-проверка -- будет выполнен select на предмет того, чтобы non-dirty поля совпадали. При использовании в кластере timestamp лучше не использовать.

O> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>том же кэше говорим?
O> Пока всегда хватало сурогатного Int64.
Ответил ниже, в комменте после Ziaw

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

O>> В том то и дело, что записимости возможно нужны.
MC>Подробнее? Как они влияют на пример?
O>> В зависимости от обстоятельств — мердж или откат или накат. В зааисимости от той же логики предметной области.
MC>Мы сейчас конкретный пример пытаемся разобрать. Какие там обстоятельства? Вы опять от конкретного примера уходите в абстракцию.
MC>Или можете ответить "я не знаю как лучше, подскажите"?

Тот же пример с клиентами и договорами, которых выгрузили на клиента, изменили, а при апдейте выяснилось, что клиент, или один из его контрактов изменен. Теперь предположим, что в соответствии с предметной областью, в таком случае возможны следующие варианты:
1. Изменились не существенные данные клиента, например, его сесейный статус — в этом случае можно апдейтить.
2. Изменились важные данные, например,
— количество контрактов,
— данные контрактов,
— количество контрактов.
В каждом из этих случаев возможна своя логика для определения того — накатывать или откатывать.

Здравствуйте, Ziaw, Вы писали:
O>> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и том же кэше говорим?
Z>Вы говорите об одном и том же кеше, кеше второго уровня.
Z>Их гораздо больше чем два,

В NHibernate больше? Интересно.

Z>но в случае нескольких приложений работающих одновременно с базой придется использовать общий кеш или не использовать его вообще.

А почему не использовать на каждом клиенте свой кэш?

O>> Пока всегда хватало сурогатного Int64.
Z>Вам говорят о его генерации, identity это то, чего следует избегать. Используйте гуиды на худой конец, раз MSSQL не имеет нормального сиквенса.

А я о чем? Почему следует избегать identity? Без него вроде вообще никак. Гуиды слишком велики и бест практисы их не советуют.
Что подразумевается под "нормальным сиквенсом"?

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

M>>Ой-ёй, только не guid =) Он слишком рандомный; это убивает индекс, и MS-SQL плохо на них реагирует (низкой производительностью). Лучше использовать HiLow или guid.comb, если уж очень хочется гуидов (в этом случае они ложатся компактным кластером).

Z>Интересно, а можно линк на эту тему?

Да. Там 9 страниц, со второй начинается интересное: "The Cost of GUIDs as Primary Keys", http://www.informit.com/articles/article.aspx?p=25862

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

O>> Не понял, что подразумевается под генератором DTO. Пока решено гнять тонкие бизнес-объекты, а в тонких местах — DTO.
M>Если объекты таки будут толстыми, то писать для них вручную DTO и код Rich Object <-> DTO затруднительно. Otislib -- это object-2-object mapper, который позволяет задать, как трансформировать объекты один в другой, и не писать вручную код, который должен будет это делать.

А, ясно. Объекты будут тонкими, надеюсь вообще избежать DTO, но знать что это решаемо на будующее очень полезно, спасибо.

O>> Сейчас начинаю понимать, что наличие единого сервера не нужно, поэтому клиенты будут просто получать из БД (от NHibernate) бизнес объекты и лочить/апдейтить их самостоятельно, а не через сервер. Соответственно, необходимость в DTO отпадает, как я понимаю.
M>Хм, интересно, как вы в отсутствии единого сервера организуете общий кэш? У вас на каждом клиенте планируется иметь фабрику сессий NHibernate?

Если под сервером понимается сервер приложения, то по возможности хотелось бы его избежать — вроде возможность есть. А в чем проблема иметь на каждом клиенте свою фабрику и свой кэш? При insert/update/delete все равно в БД лезть, а на чтение кэш может пригодится; в случае же коллизий при обновлении устаревших данных (в оптимистической блокировке) спасет версионность объектов.
В сервере с общей бизнес-логикой необходимости пока не вижу. Единственное, контролерам на клиентах может понадобиться обратная связь от общей БД, но это, думаю, можно будет решить периодическими запросами с клиентов на обновление по мере надобности. На крайняк, может спасет паттерн публикатор/подписчики.

O>> Да, решено уже по мере надобности сочетать разные блокировки. Пугает только, что это может вылиться в большой объем логики обработки исключений конфликтов.
M>Воспользуйтесь PostSharp для разделения логики обработки конфликтов и остальной логики. Я пользуюсь AOP из Spring.NET, но принцип тот же.

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

O>> Я и сам догадываюсь, но все равно напишите, т.к. я не знаю как это выразить словами. То, что NHibernate поддерживает <version> я знал, но использовать не приходилось и смутно представляю реализацию в sql. Видимо при апдейте идет проверка, что свойство version = currentVersion.
M>Примерно так, как вы сказали. Если сконфигурирована проверка version (timestamp), то NHibernate при сохранении проверяет, что версия в БД -- та же, что и в объекте. Если сконфигурирована select-проверка -- будет выполнен select на предмет того, чтобы non-dirty поля совпадали. При использовании в кластере timestamp лучше не использовать.

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

O>> Кэша в NHibernate вроде всего два — один SysCache для asp.net, второй — некий Prevalence. В детали пока не вдавался. Мы об одном и
O>>том же кэше говорим?
O>> Пока всегда хватало сурогатного Int64.
M>Ответил ниже, в комменте после Ziaw

Ага, спасибо, очень познавательно.


Пока что вы единственный, с кем у меня совпадает мнение на счет инструментов.
Расскажите немного о вашем опыте. Приходилось учавствовать в подобных проектах с несколькими клиентами и общей БД?

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

Z>Конкретная стратегия зависит именно от конкретного объекта который вызвал конфликт. От логики предметной области. Она должна диктовать что в данном случае следует сделать.
Ага, я в курсе, я и хотел чтобы автор привел эту логику предметной области. С чем не согласны то?

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

O> Если под сервером понимается сервер приложения, то по возможности хотелось бы его избежать — вроде возможность есть. А в чем проблема иметь на каждом клиенте свою фабрику и свой кэш? При insert/update/delete все равно в БД лезть, а на чтение кэш может пригодится; в случае же коллизий при обновлении устаревших данных (в оптимистической блокировке) спасет версионность объектов.
O> В сервере с общей бизнес-логикой необходимости пока не вижу. Единственное, контролерам на клиентах может понадобиться обратная связь от общей БД, но это, думаю, можно будет решить периодическими запросами с клиентов на обновление по мере надобности. На крайняк, может спасет паттерн публикатор/подписчики.
Это уже мой заскок; я что-то не могу отделаться от того, что у вас 3х-звенка ) а у Вас -- обычное клиент-серверное, где сервер -- БД

O> Про кластер не понял. Что предпоолагается использовать в кластере, БД? Я пока этих механизмов не представляю. К тому же вроде постепенно появляется возможность "виртуализировать" БД на нескольких машинах в виде одной... хотя эта тема мне пока вообще мало знакома.
Имелся в виду кластер серверов приложений. Однако — вы решили, что у вас его нет. Нет сервера, нет проблем.

O> Расскажите немного о вашем опыте. Приходилось учавствовать в подобных проектах с несколькими клиентами и общей БД?

И приходилось, и участвую. На текущем месте работы 2хзвенку не застал (работал раньше, в основном), но с 3х-звенкой и толстым клиентом пришлось повозиться и вожусь до сих пор. Счас тут используется свой маппер, и так как приложение ориентировано на данные, да еще и с динамической схемой, он -- с особенностями (метаданные хранятся в БД, например) -- не то чтобы ОРМ, скорее Data2Data Mapper, но сойдет. Система старая и кривая -- легковесный и дешевый конкурент SAP MDM, мегатонны кода, постепенно отмирает. Характеристики -- 50G данных, 300-600 одновременно работающих statefull пользователей, куча опций с данными, самописное все, вплоть до сессий пользователя =) Наследие такое. Есть модуль интеграции с XI/SAP, примитивные отчеты, система диагностики и администрирования. Из-за специфики задач (данные разных пользователей пересекаются часто) использовалась в основном пессимистическая блокировка с таймаутами и прочими "вкусняшками".

На предыдущем месте работы, занимался геоданными и распределенными БД и серверами для них (может быть, слышали про ArcGIS).

Сейчас в разработке -- тоже многозвенка с UI на Silverlight, на сервере приложений -- Spring.NET, NHibernate, memcached, DSLки на Boo. Пытаемся сделать клиент максимально тонким, но с преимуществами толстого -- такими, например, как некоторая логика на клиенте и локальный персистентный кеш данных. Хотим перейти на оптимистические блокировки и более "объектную" модель хранилища. Думаю, осилим в этом году )

Как-то так. Извините, если неинтересно получилось -- про себя плохо получается рассказывать

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

O>> В сервере с общей бизнес-логикой необходимости пока не вижу. Единственное, контролерам на клиентах может понадобиться обратная связь от общей БД, но это, думаю, можно будет решить периодическими запросами с клиентов на обновление по мере надобности. На крайняк, может спасет паттерн публикатор/подписчики.
M>Это уже мой заскок; я что-то не могу отделаться от того, что у вас 3х-звенка ) а у Вас -- обычное клиент-серверное, где сервер -- БД

Это наверно я ввел в заблуждение темой топика

O>> Расскажите немного о вашем опыте. Приходилось учавствовать в подобных проектах с несколькими клиентами и общей БД?
M>И приходилось, и участвую. На текущем месте работы 2хзвенку не застал (работал раньше, в основном), но с 3х-звенкой и толстым клиентом пришлось повозиться и вожусь до сих пор. Счас тут используется свой маппер, и так как приложение ориентировано на данные, да еще и с динамической схемой, он -- с особенностями (метаданные хранятся в БД, например) -- не то чтобы ОРМ, скорее Data2Data Mapper, но сойдет. Система старая и кривая -- легковесный и дешевый конкурент SAP MDM, мегатонны кода, постепенно отмирает. Характеристики -- 50G данных, 300-600 одновременно работающих statefull пользователей, куча опций с данными, самописное все, вплоть до сессий пользователя =) Наследие такое. Есть модуль интеграции с XI/SAP, примитивные отчеты, система диагностики и администрирования. Из-за специфики задач (данные разных пользователей пересекаются часто) использовалась в основном пессимистическая блокировка с таймаутами и прочими "вкусняшками".
M>На предыдущем месте работы, занимался геоданными и распределенными БД и серверами для них (может быть, слышали про ArcGIS).
M>Сейчас в разработке -- тоже многозвенка с UI на Silverlight, на сервере приложений -- Spring.NET, NHibernate, memcached, DSLки на Boo. Пытаемся сделать клиент максимально тонким, но с преимуществами толстого -- такими, например, как некоторая логика на клиенте и локальный персистентный кеш данных. Хотим перейти на оптимистические блокировки и более "объектную" модель хранилища. Думаю, осилим в этом году )
M>Как-то так. Извините, если неинтересно получилось -- про себя плохо получается рассказывать

Интересно, а главное, что у меня такого опыта нет, но скорее всего предстоит ) Если что по архитектуре буду консультироваться, если не против, потому как любителей Spring.NET + NHibernate не много видел ( Есть еще на этом форуме один любитель — Нахлобуч, но его застать так же трудно.

Мне вот сейчас интересно стало как общий случай трехзвенки реализуется. Логика работы с данными выносится на сервер, а на каждом клиенте дополнительно своя небольшая логика? Т.е. алгоритм примерно такой? :
1. Клиент запрашивает у сервера нужные объекты через сервис.
2. Сервер получает объекты из БД и отдает на клиента, сериализуя.
3. Клиент работает с объектами через свою логику, параллельно обращаясь на сервер по необходимости (что бы залочить например объект)
4. Клиент возвращает объекты серверу с просьбой сохранить состояние, в случае проблем дополнительная логика на клиенте разруливает проблемы.
А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?
Надеюсь понятно излагаю )

Еще мне интересно как разбор ошибочных состояний в БД производится (при обнаружении такого состояния).
Что в 2-х звенке, что в 3-х — неужели только логи?

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

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

O> Мне вот сейчас интересно стало как общий случай трехзвенки реализуется. Логика работы с данными выносится на сервер, а на каждом клиенте дополнительно своя небольшая логика? Т.е. алгоритм примерно такой? :
O> 1. Клиент запрашивает у сервера нужные объекты через сервис.
O> 2. Сервер получает объекты из БД и отдает на клиента, сериализуя.
O> 3. Клиент работает с объектами через свою логику, параллельно обращаясь на сервер по необходимости (что бы залочить например объект)
O> 4. Клиент возвращает объекты серверу с просьбой сохранить состояние, в случае проблем дополнительная логика на клиенте разруливает проблемы.
O> А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?
O> Надеюсь понятно излагаю )

Излагаете понятно, и алгоритм примерно такой.Но нюансов много: пп. 2 и 3 могут быть оба, могут быть совмещены или 3 не вызываться, с этим все ясно, думаю. Лочатся так же не только сами объекты, но и целые их логические наборы (все то, что вовлекается в UnitOfWork, например). Чтобы не было неожиданных обновлений (юзеры пугаются=)) перед погружение "вглубь" данных иногда приходится делать снэпшоты наборов данных -- они тоже хранятся на сервере. Скажем, при поиске в большом массиве объектов по условию найдено 1000 объектов, размещенных в UI на 50 страницах. При редактировании записи №342 так, что она больше не попадает под условие и листании набора найденных объектов, хотелось бы, чтобы запись по-прежнему осталась в наборе.
Ну, сервис, через который объекты запрашиваются у сервера, у нас -- WebService. Не спрашивайте почему так, тянется еще с fw 1.1 =). Основной критерий был -- обеспечить транспорт через http + удаленный мониторинг состояния и версий.

O> А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?
Все зависит от того, насколько клиент "тонкий". Если это web-приложение, то да -- вся логика лежит на сервере. Так у нас устроен сервис развертывания обновлений, например.

O> Еще мне интересно как разбор ошибочных состояний в БД производится (при обнаружении такого состояния).
O> Что в 2-х звенке, что в 3-х — неужели только логи?
У нас в основном блокировки объектов средствами бизнес-логики (реестр с пометками, что такой-то физический или логический объект редактируется). Для некоторых объектов разрешено только эксклюзивное редактирование, для некоторых -- совместное. При сохранении происходит merge данных (скажем, если 1 пользователь отредактировал описание, а другой -- приаттачил документ, то нет смысла откатывать, можно безболезненно смержить) или отказ с уведомлением одного из пользователей; в зависимости от полномочий он имеет право только повторить редактирование или даже перетереть изменения другого. Раньше куча логики была в БД (опять же, исторически сложилось, что мы мигрировали на 3хзвенку с 2хзвенки, да еще и с с++builder --> c#, а там было много кода в БД на T-SQL), счас постепенно сумели от этого избавиться.

Или вы про какие-то другие ошибочные состояния говорите?

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


Все поскипаное понял, спасибо.

M>Или вы про какие-то другие ошибочные состояния говорите?

Да, я имел ввиду состояния, нарущающие бизнес-логику, например, в БД у клиента хранятся записи, что он был в одно и то же время в разных местах или что-нибудь такое, причем повторить такое не получается. Обычно можно строить предположения и проверять их по очереди, зная архитектуру, но это часто долго, а иногда и придумать что-то сложно. Я представляю, что только по логам, в которые писать все опериции над объектами и соответственно идентификаторы объектов. Но лог писать на каждое действие — это несколько бъет по производительности, а если клиент удаленный, то все еще хуже т.к. придется просить клиента, чтобы он логи прислал, или делать механизм выгрузки логов... в общем не ясно какие механизмы применять в случае обнаружения ошибочных данных в БД.