есть проблема: коллизии
есть инструменты: навернуть, откатать, смеждить и т.д.
пишите что является критерием выбора инструмента: — самый простой пример критерия — это решение проблемы, если в результате использования этого критерия все равно есть несколько инструментод — добавляете допольнительные критерии: скорость, или возможность сопровождения и т.д.
теперь возникает вопрос — что является решением вашей проблемы. а решение описано в документе SRS, в разделе функциональные требования, где описано поведение системы... теперь вы смотрите какой из интрументов обеспечивает вам требуемое поведение системы и используете его. если требовни нет берете аналитика или того кто выполняет его роль и выявляете эти требования. т.е. у носителей знаний выявляете как должна функционировать система при той или иной ситуации ...

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

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

O> Расскажите это заказчику, к которому будут идти недовольные клиенты
насколько я понимаю, заказчик именно к вам и обратился потому, что именно вы и являетесь специалистом в реализации, а не он... по этому именно на вас как на разработчике( специалисте в реализации) лежит ответсвенность за успешную реализацию проекта. клиент всегда имеет свое видение, но его видение базируется на его опыте, на его багаже заний в данной области — у вас как у исполнителя этот багаж должен быть больше. по этому при реализации проекта ваше мнение имеет довольно высокий приоритет — я хочу сказать, что убеждайте вашего клиента и не давайте ему вами рулить как он этого хочет. потму что ответ держать в любом случае вам как исполнителю... и аргументы типа ну вы же сами говорили как нужно в последствии не конают, потому как аргумент заказчика простой — а кто из нас специалист ?

(вы — это абстракция канторы, или IT отдела если в рамках канторы работаете)

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

G>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
не понял — что она сосет ? человеческие ресурсы на реализацию? системные ресурсы сервера ?
как на меня любой архитектурный стиль, трезвенка, SOA и т.д. привносит свои плюсы и минусы, и в результате выбор — это компромис... необходимо только составить критерии выбора.

G>И ты предлагаешь держать открытой сессию, пока клиент редактирует объект? Масштабируемость будет нулевая.
да это правда — хуже не придумаешь... такое решение очень плохо сказывается на производитлеьности, масштабируемости системы... я сомневаюсь что кто-то захочет воплотить такое решение по собственной воле.

O>> Решение N2:
O>> Сразу скажу, что это решение я до конца не понял, однако как альтернативу то же хотелось бы рассмотреть.
O>> Решение заключается в том, чтобы каждый объект требуемый клиенту маршалить из сервера на клиент по ссылке. Решение нацелено на то, чтобы устранить проблему неактуальности данных на клиенте. Т.е. получается, что на клиенте всегда будет ссылка на актуальный объект. При этом, как я понимаю, на клиенте перед каждой операцией нужно будет лочить объект и проверять, что его состояние не изменилось с момента последнего чтения, после чего обновлять и разлочивать.
O>> Проблемы (и вопросы) решения N2:
O>> 1. до конца не понятен механизм разруливания коллизий и возможные сложности;
O>> 2. как работать с временем жизни объектов?
O>> 3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
O>> 4. будут ли маршалиться NHibernatе'овские прокси?
G>Это худший вариант развития событий.
G>1)На любое дергание объекта придется бегать на сервер
G>2)Все изменения надо передавать клиентам
G>3)Проблемы с контролем времени жизни
.Net Remoting например, на сервероном стабе можно организовать отслеживание изменений. там же в ремоутинге есть сервис управления жизнью объекта.


O>> Воообще, интересуют любые решения практикующих разработчиков

самое простое что приходит в голову это создание несколко представлений для одной модели. где контроллер получая изменения модели и оповещает представления об изменениях, или в зависомости от клиента и требований не оповещает. а вообще без конкретных примеров поведения как я уже писал выше проблема имеет два решения, первое:или вы лочите объект и делаете изменения и разлочиваете, его при этом даете другим клиентам возможность читать данные, но не изменять их. второе:или вы даете возможность нескольким клиентам брать данные с возможностью изменений в этом слечае вам придется решать проблемы с отслеживанием изменений и соотвественно при необходимости мерджем данных...
сюда в зависимости от требований и критичности можно добавить нотификацию об изменениях и возможности редактировании... кстати пример первого поведения реализован в ворде, а в VSS реализованы оба подхода...

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

O>> Расскажите это заказчику, к которому будут идти недовольные клиенты
VPV>насколько я понимаю, заказчик именно к вам и обратился потому, что именно вы и являетесь специалистом в реализации, а не он... по этому именно на вас как на разработчике( специалисте в реализации) лежит ответсвенность за успешную реализацию проекта. клиент всегда имеет свое видение, но его видение базируется на его опыте, на его багаже заний в данной области — у вас как у исполнителя этот багаж должен быть больше. по этому при реализации проекта ваше мнение имеет довольно высокий приоритет — я хочу сказать, что убеждайте вашего клиента и не давайте ему вами рулить как он этого хочет. потму что ответ держать в любом случае вам как исполнителю... и аргументы типа ну вы же сами говорили как нужно в последствии не конают, потому как аргумент заказчика простой — а кто из нас специалист ?

Это понятно

VPV>(вы — это абстракция канторы, или IT отдела если в рамках канторы работаете)

Я — пока разработчик и соархитектор за зарплату На себя ответственность пока брать не могу из-за опыта, иначе бы тут вопросы не задавал

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

VPV>есть проблема: коллизии
VPV>есть инструменты: навернуть, откатать, смеждить и т.д.
VPV>пишите что является критерием выбора инструмента: — самый простой пример критерия — это решение проблемы, если в результате использования этого критерия все равно есть несколько инструментод — добавляете допольнительные критерии: скорость, или возможность сопровождения и т.д.
VPV>теперь возникает вопрос — что является решением вашей проблемы.

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

VPV>а решение описано в документе SRS, в разделе функциональные требования, где описано поведение системы... теперь вы смотрите какой из интрументов обеспечивает вам требуемое поведение системы и используете его. если требовни нет берете аналитика или того кто выполняет его роль и выявляете эти требования. т.е. у носителей знаний выявляете как должна функционировать система при той или иной ситуации ...

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

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

Вот мне и интересно: как именно так и этак.

VPV>вот по этому ребята, которые вам пытаются помочь советом, и спрашивают о конкретных примерах поведения системы, чтобы понять какой интсрумент вам посоветовать. ответить "я не знаю как лучше, подскажите"?

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

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

G>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
VPV>не понял — что она сосет ? человеческие ресурсы на реализацию? системные ресурсы сервера ?
VPV>как на меня любой архитектурный стиль, трезвенка, SOA и т.д. привносит свои плюсы и минусы, и в результате выбор — это компромис... необходимо только составить критерии выбора.

Очень красиво сказано, однако чаще решение принимаются не столь идеалистично. У всех есть некоторый опыт, все имеют некую консервативность и придерживаются некоторого стиля... Я вот, по собственной воле вряд ли буду делать толстую domain model или работать с dataset'ами, хотя опыта в этом у мало для того чтобы так категорично судить.

G>>И ты предлагаешь держать открытой сессию, пока клиент редактирует объект? Масштабируемость будет нулевая.
VPV>да это правда — хуже не придумаешь... такое решение очень плохо сказывается на производитлеьности, масштабируемости системы... я сомневаюсь что кто-то захочет воплотить такое решение по собственной воле.

Согласен.

O>>> Проблемы (и вопросы) решения N2:
O>>> 1. до конца не понятен механизм разруливания коллизий и возможные сложности;
O>>> 2. как работать с временем жизни объектов?
O>>> 3. как быть, если клиент на некоторое время отвалиться от соединения с сервером?
O>>> 4. будут ли маршалиться NHibernatе'овские прокси?
G>>Это худший вариант развития событий.
G>>1)На любое дергание объекта придется бегать на сервер
G>>2)Все изменения надо передавать клиентам
G>>3)Проблемы с контролем времени жизни
VPV>.Net Remoting например, на сервероном стабе можно организовать отслеживание изменений. там же в ремоутинге есть сервис управления жизнью объекта.

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

Здравствуйте, Ocenochka

S>>А вот это очень распространённое заблуждение — верить что программа ценна сама по себе, и не потребуется интеграция с другими системами.
O> А если потребуется, от что? Нельзя будет учесть версию объекта, или транзакционность БД как-то отменится?

Вы меня неправильно поняли — я писал про блокировку намерения — она имеет смысл только для вашего приложения. Но и optimistic concurrency это тоже относится.

S>>Данные у вас лежат в СУБД — любой запрос может помацать их несмотря ни на какие псевдоблокировки.
O> Раскажите, наконец, каким образом? Например, есть объект "клиент" у него есть свойство "счет". Объект имеет версию, лежит в БД. Дав клиента забирает его из БД, изменяют и пытаются положить обратно предварительно проверив версию объекта. Как возможна коллизая, эсли "помацать" — это коллизия ?

Легко, если клиент другой системы не использует оптимистическую блокировку и созраняет изменения после вас. Если не делать проверки силами самой СУБД — через триггеры или хранимые процедуры.

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

O> Решением моей проблемы является архитектура, которую на каждое новое требование заказчика не надо будет сильно переписывать.
как говрится — дьявол кроется в деталях архитектура это карта описывающая способ решения, но сама по себе не является ее решением, имеено чатью архитектурного процесса и является создание и описание решения проблемы... (но это вне темы данного топика)

VPV>>а решение описано в документе SRS, в разделе функциональные требования, где описано поведение системы... теперь вы смотрите какой из интрументов обеспечивает вам требуемое поведение системы и используете его. если требовни нет берете аналитика или того кто выполняет его роль и выявляете эти требования. т.е. у носителей знаний выявляете как должна функционировать система при той или иной ситуации ...

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

собственно кто какие роли в проекте играет не имеет значени — это может сказываться толко на качестве результата, я про аналитика сказал для того, что прежде чем решать проблему вам нужны буду знания о требуемом поведении системы в том или ином случае (ее состоянии)...
пример:
вы клиент 1, я клиент 2. вы бирете Business Entity (BE) и я биру ту же BE. оба делаем изменения, чью версию сохраняем ? при такой постановке вопроса — проблема решения не имеет, но как только мы введем допольнительные правила — например по премени изменений (вы раньше взял я позже), по приоритеру ролей (у вас роль с низким приоритетом и для внесения измений в хранилище ваши данные должны еще пройти утверждение у менеджера), т.д. правила могут быть разные... т.е. нужно уточнить необходимое поведение системы.

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

O> Обратная связь — это когда сервер уведомляет клиентов об изменении. А когда с клиента на сервер передавать — сразу или при нажатии на сейв — это не обратная связь.

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

нажатие на кнопки сохранить на клиенте 1 не может быть уведомлением сервера для других клиентов, — это может быть триггером контроллера для запуска процесса сохраниение, в рамках которого можгут быть уведомлены об изменениях модели другие клиенты, а могут быть и не уведомлены

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

проблемы могут быть разные — в если хотите иметь их полный список — опишите UC сохранениея BE в формальной форме — и для каждого пункта в основном потоке сделайте алтернативу... чем точнее будет ваш основной поток, тем точнее вы сможите составить список возможных альтернатив, тем полнее будет картина возможных проблем

G>>>>Создавать сферическую архитектуру в вакууме не получится.
да это правильно — хотя бы потому что архитектура это решение проблемы — нет проблемы нет решения

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

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

Как делал я: практически на каждый use case редактирования у сервера есть 2 метода, взять и сохранить. Берется DTO в котором есть все необходимые данные, на сохранение приходит тоже оно. Если при сохранении случился конфликт — сервер может попытаться разрулить его автоматически, если не получилось кидает экзепшн, далее разруливать приходится пользователю на клиенте.

O> А в случае тонкого клиента все операции, в том числе модификация производятся через сервер?

Это и есть случай тонкого клиента. В случае толстого клиента сервер выглядит как набор DAO, вся логика работы с данными рулится клиентом.

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

А чем не устраивают логи? Возьмите log4net, отлично фильтруются снаружи, есть средства онлайн мониторинга, можно ошибки кидать по почте.

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

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

Ну да, вобщем-то я сам те же доводы приводил в форуме БД, даже тесты делал, а мне твердили GUID'ы наше все. Не пойму, что мешает команде MSSQL сделать нормальный сиквенс, который подерживают практически все промышленные субд. Впрочем оффтопик.

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

Z>Ну да, вобщем-то я сам те же доводы приводил в форуме БД, даже тесты делал, а мне твердили GUID'ы наше все. Не пойму, что мешает команде MSSQL сделать нормальный сиквенс, который подерживают практически все промышленные субд. Впрочем оффтопик.

Плохому танцору (т.е. MsSQL) .. )) Нормальный сиквенс можно симулировать триггером и таблицей, может, поэтому и не хотят -- и так прокатывает.
Насчет "guid'ы наше все" -- для таких оригиналов в nhibernate есть guid.comb, как я уже сказал

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

Z>Как делал я: практически на каждый use case редактирования у сервера есть 2 метода, взять и сохранить. Берется DTO в котором есть все необходимые данные, на сохранение приходит тоже оно. Если при сохранении случился конфликт — сервер может попытаться разрулить его автоматически, если не получилось кидает экзепшн, далее разруливать приходится пользователю на клиенте.
Именно поэтому есть желание отказаться от SOAP-service и перейти на REST-like DAO -- не нужно будет по каждому чиху менять WSDL. (О своем: вообще считаю, что в таком случае SOAP WebService был выбран неудачно)

Z>Это и есть случай тонкого клиента. В случае толстого клиента сервер выглядит как набор DAO, вся логика работы с данными рулится клиентом.
Если сервер исключительно DAO-контейнер, то чисто толстый клиент в 3хзвенке иметь смысла не вижу, тем более при наличии Nhibernate ; лучше тогда 2хзвенка + shared cache. Тут, конечно, свои нюансы, например, интеграция с другими системами, требующая сервера, или хитрая репликация средствами серверной логики.

Z>А чем не устраивают логи? Возьмите log4net, отлично фильтруются снаружи, есть средства онлайн мониторинга, можно ошибки кидать по почте.
Мне кажется, он что-то другое имеет в виду )

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

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

У нас есть логи правок, хранящиеся в БД -- например, по сохранению объектов в таблицу логов кладется предыдущее состояние объекта, упакованное в xml и пожатое для компактности. Потом с него можно восстановить объект на нужную версию. Периодически лог чистится согласно админ. политикам. Для некоторых сложных объектов ведется история правок как понятия предметной области.
Счас это все делается триггерами, но есть желание в новой системе перевести это на message-based system -- MSMQ или аналог (ApacheMQ, RabbitMQ), чтобы БД была меньше загружена и не сказывалось на производительности в целом.

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

Логгирование при помощи log4net -- есть, но так, для ясности, оно в работе не используется, только при отладке багов.

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

M>Именно поэтому есть желание отказаться от SOAP-service и перейти на REST-like DAO -- не нужно будет по каждому чиху менять WSDL. (О своем: вообще считаю, что в таком случае SOAP WebService был выбран неудачно)

Согласен, но у нас вообще remoting+binary serialization по некоторым причинам.

Z>>Это и есть случай тонкого клиента. В случае толстого клиента сервер выглядит как набор DAO, вся логика работы с данными рулится клиентом.
M>Если сервер исключительно DAO-контейнер, то чисто толстый клиент в 3хзвенке иметь смысла не вижу, тем более при наличии Nhibernate ; лучше тогда 2хзвенка + shared cache. Тут, конечно, свои нюансы, например, интеграция с другими системами, требующая сервера, или хитрая репликация средствами серверной логики.

+1

M>Мне кажется, он что-то другое имеет в виду )

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

S>>>А вот это очень распространённое заблуждение — верить что программа ценна сама по себе, и не потребуется интеграция с другими системами.
O>> А если потребуется, от что? Нельзя будет учесть версию объекта, или транзакционность БД как-то отменится?
S>Вы меня неправильно поняли — я писал про блокировку намерения — она имеет смысл только для вашего приложения. Но и optimistic concurrency это тоже относится.

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

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

M>У нас есть логи правок, хранящиеся в БД -- например, по сохранению объектов в таблицу логов кладется предыдущее состояние объекта, упакованное в xml и пожатое для компактности. Потом с него можно восстановить объект на нужную версию. Периодически лог чистится согласно админ. политикам. Для некоторых сложных объектов ведется история правок как понятия предметной области.
M>Счас это все делается триггерами, но есть желание в новой системе перевести это на message-based system -- MSMQ или аналог (ApacheMQ, RabbitMQ), чтобы БД была меньше загружена и не сказывалось на производительности в целом.
M>Есть также логгирование исходящих запросов на интеграцию со сторонними системами, логгирование входящих/исходящих репликаций. Есть еще автоматизированный валидатор, но его возможности в настоящий момент ограничены проверкой метаданных.
M>Логгирование при помощи log4net -- есть, но так, для ясности, оно в работе не используется, только при отладке багов.


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

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

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

G>>>>Наверное при нажатии save, но в таком случае и передавать на сервер не надо.
O>>> Как не надо? А как об изменении смогут узнать другие клиенты?
G>>Сам же написал что без обратной связи. Тогда зачем до save куда-то что-то передавать?

O> Обратная связь — это когда сервер уведомляет клиентов об изменении. А когда с клиента на сервер передавать — сразу или при нажатии на сейв — это не обратная связь.
Это я понял, я не понял зачем передавать что-то на сервер до нажатия save без обратной связи.

G>>>>Создавать сферическую архитектуру в вакууме не получится.
O>>> Однако, глядя на ваши ответы, я считаю, что у вас это вполне получается Без обид.
O>>>Просто я не вижу у вас понимания решения N1.
G>>Это у тебя нету понимания решения N1, я такие решения в разных видах уже делал.
O> С тонкой domain model делал?
Я только с тонкой сейчас и работаю.

O>>>То, что вы пробовали городить dataset'ы — это я уже выяснил
G>>Мимо. Как раз решения с dataset я предпочитаю не городить, я один раз начал такое делать и быстро отказался.
O> А как делал?
Что именно?

O>>>>>>> Воообще, интересуют любые решения практикующих разработчиков, а так же мнения относительно адекватности двух приведенных мною решений. Адекватность прошу оценивать по времени написания, отладки и поддержки.
G>>>>>>Оба неадекваты на 99%
O>>>>> Предлагайте!
G>>>>Сделать кнопку Save, по которой сохранять изменения.
G>>>>Далее 3 варианта:
G>>>>1)Локальная реплика БД, которая хранит измененные данные (dataset или SQL CE) и периодическая синхронизация с сервером (передача changeset датасета или Sync Services для SQL CE)
O>>> В задаче сказано, что БД — одна.
G>>И что? SQL CE — несколько dll и больше ничего не надо

O> Я знаю, что такое SQL CE и работал с ней, однако, синхронизация должна быть чаще чем раз в минуту. Городить для этого репликацию из локальных БД... Синхронизацию руками проводить? Чем локальный кэш NHibernate хуже, чем локальная БД?
Есть sync framework, который все сам делает. А лучше кеша потому что всетаки РСУБД, а не коллекция объектов в памяти.
Но если актуальность информации важна, то лучше локальным кешированием оперативных данных не заниматься. Только справочники.

G>>>>2)Написать кучу сервисов и DTO
O>>> Это зачем и к чему?
G>>Ко всему. Если клиент не толстый, то лучше увеличить гранулярность обращения к серверу. Для этого потребуется метод сервиса и вероятнее всего DTO.
O> Клиент толстый.
Если толстый — тогда вариант ниже.

G>>>>3)Воспользоваться EF\Linq2SQL+ADO.NET Data Services
O>>> Каким образом?
G>>Создть модель в EF дизайнере, создать сервис ADO.NET, сделать клиент.
O> Не пробовал EF, слышал негативные отзывы, как работает — не представляю. В чем преимущества?
Ты EF при таком подходе даже не увидишь
Посмотри примеры с ADO.NET Data Services — удивишься. Через полгода как раз доделают сихнхронизацию через эти сервисы и допилят нужный функционал (сейчас доступен в CTP).


O>>> Есть четкая задача, которую я обозначил дважды, повторю еще раз: есть два клиента, работающих с общей БД. Как реализовать их работу при отсутствии коллизий?
G>>Наверное при наличии коллизий. Варианта как всегда два:
G>>1)пессимистичная блокировка — когда данные могут меняться только одним клиентом в один момент времени.
G>>2)оптимистичная блокировка, когда оба редактируют данные, если при попытке сорхнанить версии не сопадают — исправить конфликт и попытаться еще раз.
G>>Оптимистичная блокировка на самом деле блокировкой не является, несмотря на назание, и в некоторых случаях не работает.

O> Почему не работает? У же который раз пишут, что может не работать, однако я не представляю как это возможно в случае наличия версии в каждой сущности и транзакционной БД.
Сценарий.
Для корректного обновления X надо прочитать из Y, выполнить запрос на внешний сервис с данными из Y, записать результат в X.
Один клиент читает Y, начинает выполнять запрос, в этот момент другой клиент меняет Y. Так как первый клиент Y не менял, то конфликт версий при сохранении даже не будет проверяться, тем не менее данные будут несогласованы.

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

Z>Как делал я: практически на каждый use case редактирования у сервера есть 2 метода, взять и сохранить. Берется DTO в котором есть все необходимые данные, на сохранение приходит тоже оно. Если при сохранении случился конфликт — сервер может попытаться разрулить его автоматически, если не получилось кидает экзепшн, далее разруливать приходится пользователю на клиенте.

Спасибо, опять все понятно

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

Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.

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

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

Z>>>Примеры неDDDшных конструкций в студию.
G>>В основном дополнительные классы для работы с произвольными выборками. Не помню уже все давно это было и на делфи.
Z>Почему ты решил, что эти кклассы "неDDDшные"? Рич модель не обязана состоять только из персистных классов. Она отличается от тонкой только тем, что допускает логику в персистных, но нигде не говорится об обязательном отсутствии BL в других классах.
И что? Получим размазываение логики? нет уж, спасибо.

G>>Еще раз модель — часть программы. Рассматривать модель отдельно от программы смылса нету.
G>>Не бывает модель ценной сама по себе.

Z>>>Это не философия, если ты не выделяешь подобного ядра — тебе надо быть уверенным во всей программе.
G>>А если бы выделял ядро, то не надо было бы быть уверенным?

Z>Это уже пошла философия. Есть критические ошибки в БЛ, которые стоят очень дорого. Есть некое ядро, при корректности которого нарушить БЛ сложно/невозможно. Чем компактнее это ядро, тем легче его поддерживать. Я убежден, что рич модель позволяет сделать такое ядро более компактным и проще поддерживаемым. Правда требует большей квалификации при его дизайне.
Уж точно философия. Я всетаки тесты предпочитаю чтобы быть уверенным.

Z>Пример из практики, при переводе на клиент-сервер одной из систем сделали из рич модели тощую, руководствуясь примерно теми же мотивами, что и ты декларируешь. Ядро логики мне не удалось изолировать так же хорошо как и в жирной, хотя я проектировал ее на три года позже чем жирную (смею надеяться, что за три года в голове прибавилось ). Реюз кода уменьшился и, как я ни старался, сейчас требуется намного больше знаний о системе для написания новой логики. Сейчас я уже не так уверен, что решение проблем рич модели было бы дороже. И уж точно не сомневаюсь в праве рич моделей на жизнь.
Я даже не смоневаюсь что переделка rich в anemic даст такой эффект.
Это примерно как попробовать переделать OO-программу в функциональную.

G>>Я вообще-то тесты пишу.
Z>Дада, и в твоих программах больше нет ни одной ошибки. Рич модель несоместима с тестами чтоли?
Совместима, только все разговоры о "ядре" больше ни к чему.