Как решить оптимистичные обновления параллелизма в приложениях .NET N-level C# .NET?

Question

Hy каждый.

В C# .net VS 2008 Я разрабатываю рамочное решение CRM N-уровня и, когда это будет сделано, я хочу поделиться им.

Архитектура основана на:

уровня доступа к данным, Entity Framework, Bussines Logic Layer, WCF и, наконец, уровень представления (выиграть формы).

Где-то я читал, что более двух уровней уровней проблематичны, что приводит к оптимистичным обновлениям параллелизма (несколько клиентских транзакций с одинаковыми данными).

В макс. 2-уровневые решения уровня, это не должно быть проблемой из-за элементов управления (например, datagridview), которые решают эту проблему самим собой, поэтому я спрашиваю себя, не лучше ли работать с уровнями 2 уровня и избегать оптимистического параллелизма проблема?

На самом деле я хочу сделать решение уровня N-уровня для огромных проектов, а не двухъярусных. Я не знаю, как решить проблемы параллелизма, подобные этому, и надеюсь получить помощь прямо здесь.

Конечно, должны быть хорошие механизмы для решения этого ... возможно, какие-либо предложения, примеры и т. Д.?

Спасибо вам в ожидании.

С наилучшими пожеланиями, Jooj

Answer 1

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

Существует два распространенных метода оптимистического разрешения параллелизма.

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

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

Here's достойное объяснение того, как реализовать простой оптимистичный параллелизм в EF.

Answer 2

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

Answer 3

Несколько вещей приходят на ум:

1) Если вы используете EF, конечно, вы don'y имеете доступ к данным слоя ?! Вы имеете в виду базу данных?

2) Вопрос с уровнями является как фидическим, так и логическим. Итак, вы имеете в виду физическое или логическое?

3) В любом многоуровневом приложении существует проблема с параллелизмом. Даже в клиент-сервере люди могут открывать форму, переходить в soemwhere и возвращаться, а затем сохранять, пока данные были изменены с помощью soemone else. Вы можете использовать отметку времени для проверки при сохранении, чтобы убедиться, что последнее обновление было, когда у вас были данные.

4) Не думайте слишком много о менее или более уровнях. Просто реализуйте функциональность как можно проще и с минимальным количеством слоев.