Паттерны Unit of work, Identity Map и сборка мусора
Не вижу проблемы.
Не вижу проблемы.проблема в том, что вводится новая хрень Session и, соответственно, наружу выставляются правила как с ней работать, когда открывать, когда закрывать, объект может быть ассоциирован с Session или не ассоциирован. Короче, заморочек много, для простых web приложений, эти проблемы не так остро стоят, а вот в трехзвенке с rich клиентом уже не так все просто.
P.S. я же написал, лишняя зависимость — это всегда плохо.
P.S. я же написал, лишняя зависимость — это всегда плохо.То есть ты не читал, когда применяется Unit of work?
В ряде систем, в том числе .net, предприняты определенные попытки сделать прозрачный распределенный GC, но пока это не особо получается.
То есть ты не читал, когда применяется Unit of work?пожалуйста, поясни ход своих мыслей.
имхо, это немного не то
Еще вот что удивляет. В той же книжке пишут, что удаленные вызовы идут
1. между БД и сервером
2. между сервером и клиентом
А решения проблемы удаленных вызовов для этих двух случаев предлагаются совершенно разные:
1. Unit of work, Identity Map, маперы там всякие и т.д.
2. Remote Facade и Data Transfer Object
1. между БД и сервером
2. между сервером и клиентом
А решения проблемы удаленных вызовов для этих двух случаев предлагаются совершенно разные:
1. Unit of work, Identity Map, маперы там всякие и т.д.
2. Remote Facade и Data Transfer Object
пожалуйста, поясни ход своих мыслей.У каждого паттерна есть Pros и Cons.
Усложнение системы путем введения новых классов (скажем, Memento зато выигрыш в абстракции.
Про связь сборки мусора с UOW или Identity Map я, честно говоря, не понял. Каким образом передача объекта UOW накладывает на использующий UOW код какую-то ответственность?
А решения проблемы удаленных вызовов для этих двух случаев предлагаются совершенно разные:Какое-то очень поверхностное суждение. С таким же успехом можно сказать, что отправка почты по SMTP - частный случай удаленного вызова, а потому и паттерны должны ему соответствовать.
С таким же успехом можно сказать, что отправка почты по SMTP - частный случай удаленного вызова, а потому и паттерны должны ему соответствовать.про ниже лежащий протокол речи вообще не было. Электронное письмо это просто сообщение с заданным стандартом форматом, а в нашем случае данные имею реляционную структуру на всех трех уровнях, а формат сообщений как раз обсуждается.
в нашем случае данные имею реляционную структуру на всех трех уровняхГде это в RPC данные имеют реляционную структуру?
Где это в RPC данные имеют реляционную структуру?я не про RPC я про наш случай
, ибо не фиг им прибывать в другой структуре, если они хранятся в реляционной 
У каждого паттерна есть Cons.Не у каждого, только если параметр - список.
ибо не фиг им прибывать в другой структуре, если они хранятся в реляционнойВот за это, кстати, не люблю .NET
Хотя дело вкуса.
Реализуй IdentityMap на слабых ссылках (WeakReference) - получишь обратно прелести автоматической сборки мусора.
UnitOfWork-у ни о чем париться не нужно. Ему нужно знать, как изменился объект, если изменился.
Хотя при клонировании объектов (а при распределенных вычислениях, особенно с отсоединенными клиентами, это неизбежно) гимора с коллизиями можно обрести достаточно. Тут придется юзать Pessimistic или Optimistic Lock-и - в зависимости от задачи.
UnitOfWork-у ни о чем париться не нужно. Ему нужно знать, как изменился объект, если изменился.
Хотя при клонировании объектов (а при распределенных вычислениях, особенно с отсоединенными клиентами, это неизбежно) гимора с коллизиями можно обрести достаточно. Тут придется юзать Pessimistic или Optimistic Lock-и - в зависимости от задачи.
Реализуй IdentityMap на слабых ссылках (WeakReference) - получишь обратно прелести автоматической сборки мусора.
хи
, если я изменил объект, а потом сборщик мусора его убрал, то как мне восстановить объект? из базы не катет, потому что там старые данные.Ему нужно знать, как изменился объект, если изменился.и не только, ему еще нужно знать все измененные объекты, чтобы сделать commit в базу, соответственно опять внутренний кэш.
> если я изменил объект, а потом сборщик мусора его убрал
измененные объекты не собирай через сборщик мусора
измененные объекты не собирай через сборщик мусора
хиПока объект не изменен, он просто лежит в списке слабых ссылок и можетбыть собран. При следующем запросе к БД ты сначала делаешь lookup вэтом списке и смотришь, не лежит ли там нужный тебе объект. Если нет или есть, но его уже собрали, опять придется лезть в БД.
Если ты изменил объект - значит он попал в список измененных объектов, значит на него есть жесткая ссылка, значит сборщик его собрать не посмеет.
Минус этого всего в том, что он хорошо работает, пока ты объекты ищешь по ID. А как дойдет дело до более сложных запросов, будешь руками реализовывать подмножество SQL на шарпе. Хотя тут может помочь наступающий Linq.
и не только, ему еще нужно знать все измененные объекты, чтобы сделать commit в базу, соответственно опять внутренний кэш.UnitOfWork как раз и держит в себе все связанные объекты и следит за их изменением. Да. Он представляет из себя "внутренний кэш". Че в этом плохого?
UnitOfWork от Микрософта - это DataSet. В нем таблицы - наборы однотипных объектов. Датасет умеет сохранять ссылочную целостность и знает, кто как изменился.
Пока объект не изменен, он просто лежит в списке слабых ссылок и можетбыть собран. При следующем запросе к БД ты сначала делаешь lookup вэтом списке и смотришь, не лежит ли там нужный тебе объект. Если нет или есть, но его уже собрали, опять придется лезть в БД.тогда смысл этой всей затеи теряется (ограничение по памяти пока не обсуждается)
UnitOfWork от Микрософта - это DataSet. В нем таблицы - наборы однотипных объектов. Датасет умеет сохранять ссылочную целостность и знает, кто как изменился.не совсем, DataSet хранит все об изменениях данных, но commit в базу он не делает. Т.е. DataSet не обязан находиться рядом с базой, это вообще сериализуемый объект, предназначенный для распредеоенных вычислений (по крайней мере так было задумано
).Но на DataSet наворотили много чего причем сделали это не модульно, а все в одном монолите — связке классов.
Почему же теряется!
Ты че ваще затеял-то?
Ты че ваще затеял-то?
Да лучше бы давно сделали ORM нормальный.
Может ща с Linq и всем, что ему сопутствует, получится что-то человеческое.
Может ща с Linq и всем, что ему сопутствует, получится что-то человеческое.
Может ща с Linq и всем, что ему сопутствует, получится что-то человеческое.а может еще больше гемора будет
точнее скорее всего будет так, совсем простые приложения буду делаться быстро, а более менее сложные потребуют прикручивания всяких уродливых конструкций
Оставить комментарий
6yrop
Одной из ключевых вкусностей современных платформ это сборка мусора. Сборщик мусора, действительно, развязывает руки и можно безопасно выполнять довольно запутанные трюки.В широко известной книге М. Фаулера “Архитектура корпоративных программных приложение” для работы с базой данных предлагаются поведенческие паттерны Unit of work, Identity Map. И почти все прелести сборки мусора пропадают! Как было хорошо – клиент на создавал объектов, поиграл с ними, или предал другому модулю, и все, что с ними будет дальше программиста не волнует . В этих же паттернах предлагают, что модуль, который создал объекты на основе данных БД, продолжает “париться” по поводу объектов. А точнее он заставляет “париться”(задумываться) программиста о том, что объекты еще лежат в кеше и что с ними там делать.