Посоветуйте книгу по правильной реализации архитектуры "Клиент Windows - Сервер БД"

Здравствуйте. Точно не знаю в какой раздел разместить данный запрос ...

Имею базовые знания в программировании.
В качестве практики в процессе обучения стоит задача переписать программу, реализованную по архитектуре "клиент C# - сервер MS SQL".

Интересуют правильные подходы по организации приложений "клиент - сервер", а именно хотелось бы получить ответы, рекомендации и практические подходы на подобные вопросы:
1) Как правильно разделять логику между клиентом и сервером: что оставлять на уровне клиента (толстого клиента), а что лучше перенести на сервер БД;
2) Как правильно реализовать совместный доступ к данным: что, когда и как часто грузить или обновлять;
3) Как правильно работать с транзакциями и блокировками;
4) Как избежать проблем с одновременным доступом к БД и одновременному изменению одних и тех же данных;
5) Может есть какие-нибудь рекомендации по построению структуры классов для организации доступа к БД.
6) ...

В ходе предыдущих практик разработки ПО встречался в различными вариантами, которые (как мне кажется) не являются правильными, а именно:
1) На клиента фактически грузились "слепки" всех таблиц -> Дальнейшая обработка данных происходила на клиенте -> После подтверждения изменений данные перезаписывались обратно. При этом возникала проблема перезатирания одних и тех же данных. Другой клиент терял свои изменения.
2) ПО было реализовано с частым использованием транзакций, при этом постоянно возникали взаимные блокировки, когда другой клиент не мог работать.

Хочется переписать программу правильно, с правильной архитектурой и подходами.
Если ли какие-нибудь книги, где данные методы могут быть описаны ?
Привязка к языку не обязательна, но планируется использовать C# + MS SQL

0

Сообщение от Denozabr В ходе предыдущих практик разработки ПО встречался в различными вариантами, которые (как мне кажется) не являются правильными, а именно: 1) На клиента фактически грузились "слепки" всех таблиц -> Дальнейшая обработка данных происходила на клиенте -> После подтверждения изменений данные перезаписывались обратно. При этом возникала проблема перезатирания одних и тех же данных. Другой клиент терял свои изменения. 2) ПО было реализовано с частым использованием транзакций, при этом постоянно возникали взаимные блокировки, когда другой клиент не мог работать.

п.1 безусловно неправильный, поскольку клиент-сервер изначально задумывался для того, чтобы уменьшить трафик сети, т.е. чтобы по сети тащились не все таблицы, а только нужные данные, что и обеспечивается SQL-запросами.

Остальные вопросы, в том. числе п.2, достаточно специфичны для каждой СУБД, но любая продвинутая СУБД должна сама обеспечивать работу с транзакциями, блокировками, одновременным доступом к данным и проч.
Например, в Oracle вообще не существует работы вне транзакций, поскольку транзакция начинается автоматом с первым предложением SQL (первым после предыдущего COMMIT/ROLLBACK) и заканчивается на очередном COMMIT/ROLLBACK. Но это никак не приводит к взаимным блокировкам (deadlock) кроме довольно специфичных случаев да и то при обнаружении подобной ситуации Oracle автоматом откатывает одну из транзакций, чтобы другая смогла завершиться.

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

0

По поводу блокировок в Oracle ... не знаю, как сейчас, но лет 9 назад, когда начинал трудовую деятельность, то работал на заводе, который использовал ERP Intermex под управлением Oracle v.9 - так вот мы заколебались разруливать взаимные блокировки от которых висли клиенты. А так, как знаний не хватало - то мы тупо вырубали на уровне БД клиента, который вешал систему. Но это так - к слову.

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

P.S. И еще - по поводу первого подхода с загрузкой снимков таблиц на клиента - данное ПО писал программист с 15-ти летнем стажем А у меня стаж полгода

0

Сообщение от Denozabr мы заколебались разруливать взаимные блокировки от которых висли клиенты

Тогда мы по разному понимаем термин "взаимная блокировка".
Классический deadlock - это когда, например, программе надо изменить строку 1 и строку 2. Программа в первой сессии заблокировала строку 1, в другой сессии начала со 2. В результате первая сессия ждет освобождения строки 2 для завершения транзакции, вторая - освобождения строки 1. Вот такие ситуации Oracle обычно распознает (причем с достаточно древних версий) и откатывает одну из транзакций (правда нигде не оговаривается какую). Ситуация о deadlock попадает в alert.log, по этой надписи можно понять, что был именно deadlock. Чтобы такая ситуация происходила часто, ПО должно быть написано из рук вон плохо (например, произвольный порядок UPDATE строк, особенно когда часто изменяются одни и те же строки).
Если же речь идет о просто блокировках строк при их изменении или блокировки иных разделяемых ресурсов - так это один из классических способов решения при многопользовательской работе. При нормально написанном ПО такая блокировка обычно не является длительной - до первого COMMIT/ROLLBACK. Ну и в системных представлениях всегда видно, кто блокирует, а кто ждет освобождения блокировки и какой блокировки.
Я работаю с Oracle c 2000 года, сначала как разработчик, нонче и разработчик, и DBA, и никогда особенных страданий от блокировок не было.

Добавлено через 2 минуты

Сообщение от Denozabr по поводу первого подхода с загрузкой снимков таблиц на клиента - данное ПО писал программист с 15-ти летнем стажем

Так может он из этих 15 лет 14 работал с dbf-файлами. Там действительно на клиента тащится вся таблица, поскольку нет сервера, который SQL-запросом отберет только нужные данные. Я сам 8 лет на Clipper-е работал, так что немного в курсе

0