обход объекта графа из n-уровневого клиента

Question

Я студент, в настоящее время работаю над n-уровневым приложением .Net, которое использует Nhibernate + WCF + WPF.

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

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

Один из вариантов, который мне пришёл в голову, состоял в том, чтобы просто заменить NHProxies, которые лениво собирают нагрузку на клиентском уровне, на «disconnectedProxy», который получал бы связанный материал по проводам. Это означало бы, что нам пришлось бы немного расширить сигнатуру нашего веб-сервиса и сделать несколько хакерских атак на наши сгенерированные прокси, но это выглядело как хороший эксперимент T4 / other code gen.

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

Answer 1

Вы задаете очень хороший вопрос, на который, к сожалению, нет очень четкого ответа. Даже если вам удастся получить ленивую загрузку для работы над WCF (что мы смогли сделать), у вас все равно будут проблемы с использованием прокси-перехватчика. Поверьте мне, вам нужны объекты POCO на уровне клиента!

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

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

Чтобы упростить эту проблему, давайте рассмотрим два основных пробела, которые мы должны заполнить ... между базой данных и уровнем базы данных / сервиса и разрывом между сервисом и клиентом. NHibernate прекрасно дополняет первый, предоставляя ORM для загрузки данных в ваши объекты. Он выполняет достойную работу, но для достижения высокой производительности его необходимо настроить с помощью пользовательских стратегий загрузки. Я отвлекся ...

Второй разрыв между сервером и клиентом - это то, где все становится рискованным. Чтобы упростить, представьте, если вы не отправляли какие-либо сопоставленные объекты по проводам клиенту? Попробуйте создать механизм, который обменивает бизнес-объекты на объекты DTO, а также объекты DTO на бизнес-объекты. Таким образом, ваш клиент имеет дело только с DTO (конечно, POCO), и ваша бизнес-логика может поддерживать его богатую структуру. Это позволяет использовать не только механизм отложенной загрузки NHibernate, но и другие преимущества сеанса, такие как кэш-память первого уровня.

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

Answer 2

Это было для меня какое-то время, но инъекция / отключение прокси может быть не таким плохим, как кажется. Поскольку вы студент, я собираюсь предположить, что у вас есть немного времени и вы хотите немного побродить.

Если вы хотите внедрить свою собственную логику сериализации / десериализации, вы можете использовать IDataContractSurrogate , которую можно применить, используя DataContractSerializerOperationBehavior . Я сделал только несколько основных вещей с этим, но это может стоить изучить. Добавив немного забавной логики (читай: потенциально хакерской) на этом слое, вы сможете сделать его более связанным.

Здесь - это сообщение MSDN о ком-то, кто пришел к той же реализации. DynamicProxy, используемый NHibernate, не позволяет напрямую сериализовать объекты NHibernate, выполняющие отложенную загрузку.

Answer 3

Если вы действительно решили транспортировать граф объектов по сети и сохранить функцию отложенной загрузки. Взгляните на какой-то код, который я создал здесь http://slagd.com/?page_id=6. По сути, он создает поддельный сеанс на другой стороне провода и позволяет прокси-серверам nhibernate сохранять свою функциональность. Не сказать, что это правильный способ сделать что-то, но это может дать вам некоторые идеи.