Мы пересматриваем некоторые из наших практик на работе - и конкретная вещь, на которую мы сейчас обращаем внимание, - это лучший метод для работы с клиентами на основе Flex и веб-сервисами .NET.
Наш типичный подход заключается в том, чтобы сначала моделировать взаимодействия на основе требований, макетировать некоторые XML-сообщения и проверять их исправность, превращать их в XSD и, наконец, создавать классы на каждом конце, которые сериализуют в / из XML.
Это работает нормально, пока мы не попадаем в базу данных, а затем такие вещи, как Join Tables, начинают испортить всю ту работу, которую мы проделали, упрощая клиентскую часть.
Мы пытались решить эту проблему с помощью LINQ to SQL и других сопоставителей OR, но ни один из них действительно не решил проблему, не создавая более серьезных проблем.
Итак, вопрос на самом деле таков: Не рассматривая СУБД как просто хранилище объектов, существует ли лучший способ обработки сложных требований к данным без написания огромного количества кода преобразования?
Полагаю, что волшебная пуля, которую я ищу, это то, что знает, что такое таблица Join и как с ней работать, и все же позволяет мне генерировать «красивый» сериализованный XML для Flex и сохраняет сильную типизацию .NET.
Бонусные баллы, если он может анализировать SQL, требуемый для каждого метода, генерировать хранимые процедуры и использовать их. Но это, вероятно, требует слишком много :)
Примечание «Объединить таблицы»:
В нашем определении это таблица, в которой у вас есть два или более внешних ключа в качестве собственного первичного ключа.
Например:
Photos (PK PhotoID) <- PhotoTags (PK FK PhotoID, PK FK TagID) -> Tags (PK TagID)
Когда клиент Flex получает объект Photo, он также может получить список всех тегов.
Итак, это может выглядеть так:
<photo id="3">
<tags>
<tag name="park" />
<tag name="sydney" />
</tags>
</photo>
Вместо этого, инструменты OR, которые я видел, дают нам:
<photo id="3">
<phototags>
<phototag>
<tag name="park" />
</phototag>
<phototag>
<tag name="sydney" />
</phototag>
</phototags>
</photo>