Linq-to-SQL привлекает постоянных?пожалуйста помоги?

Question

Мне сложно понять некоторые архитектурные принципы при разработке службы. Если вы делаете вызов службе WCF, и она возвращает клиенту коллекцию элементов (Orders) (которые представляют собой пользовательские классы, составленные из данных сущностей LINQ-to-SQL), и у каждого элемента есть коллекция элементов (OrderItems) (один ко многим), которые также состоят из того же контекста LINQ-to-SQL. Если я сделаю еще один вызов службе и запросю конкретный OrderItem и изменим его детали на стороне клиента, как тогда первая коллекция Items поймет, что один из его OrderItem Orders изменился со стороны клиента. Я использую подход при изменении OrderItem, я отправляю объект OrderItem в службу WCF для хранения с помощью команд LINQ-to-SQL, но для обновления коллекции, которую клиент сначала вызвал, я использую интерфейс IList для поиска и замены каждого экземпляра объекта. OrderItem. Также подписка каждого элемента на событие PropertyChanged дает некоторый контроль. Это работает с некоторыми очевидными ограничениями, но как можно «правильнее» подойти к этому, возможно, управляя всеми данными, изменяющимися из самой службы. ORM? статические классы? Если это слишком сложный вопрос для ответа, возможно, какая-то ссылка или даже группа чата, в которой я могу обсудить это, поскольку я понимаю, что этот сайт предназначен для быстрых тем типа Q / A, а не для руководящих обсуждений в руководстве.

Спасибо все равно.

Крис Лич

Answer 1

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

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

Второе архитектурное требование, которое вы, похоже, описываете, - это способ синхронизации изменений между клиентами. Это очень сложная проблема. Одним из способов является создание какой-либо системы публикации / подписки, при которой после получения клиентом некоторых ресурсов из службы он также подписывается на получение обновлений об изменениях ресурса. Вы можете сделать это либо в режиме push, либо в режиме pull (pull, вероятно, проще, т.е. просто запрашивает изменения).

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