Linq to Salesforce «SQL» провайдер

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

Ядром Salesforce WSDL API является набор "query ()" "веб-методы, которые принимают команду запроса в виде строки. Синтаксис запроса похож на SQL, но не совсем (они называют его SOQL). Я не фанат «волшебных строк», поэтому я хотел бы использовать Linq в базе кода и преобразовывать IQueryable в запрос SOQL, который мне нужен в оболочке для службы. Это, конечно, возможно (L2E, L2Sql), но я хотел бы знать, есть ли ярлык, потому что, если я скажу, что на то, чтобы свернуть мой собственный, уйдет больше дня или двух, я буду "поощрен" найти другой метод (скорее всего, метод для каждого общего запроса, который использовался в старых приложениях). Если мне удастся создать синтаксический анализатор SOQL общего назначения, мы сможем использовать его в нескольких других будущих приложениях, и я буду героем. Даже если я сделаю простой, который поддерживает только определенные структуры запросов, он пройдет долгий путь, позволив мне продолжить текущий проект в стиле Linq-y, и я могу расширить его в свободное время.

Вот варианты, как я это вижу:

• Присмотритесь внимательнее к существующему провайдеру Linq2SOQL (здесь мой Google-fu подводит меня, иначе просто нет one; единственная оболочка .NET упоминает Linq только как полезное средство).
• Создайте синтаксический анализатор дерева выражений. Он должен поддерживать, по крайней мере, вызовы методов Select и Where, а также должен либо анализировать лямбда-выражения, либо манипулировать их телами методов, чтобы получить необходимые операции и проекции. Это кажется довольно сложной задачей, но, как я уже сказал, это, безусловно, возможно.
• Оберните службу в Linq2Sql или аналогичный существующий поставщик Linq, который позволит мне извлечь достаточно близкую строку запроса, отполировать ее и передать это к сервису. Их должно быть несколько десятков (хотя ни одного, который просто не появляется, AFAIK).
• Вызов Expression.ToString () (или Expression. DebugView) и манипулируйте этой строкой для создания запроса SOQL. Он будет хрупким, уродливым (за кулисами) и будет поддерживать только то, что я ищу, но предоставит элементарный перевод, который позволит мне двигаться дальше.

Что делать вы думаете? Создание парсера Linq - это больше, чем двухдневная задача для одного человека? Может ли это сделать сложное решение с участием существующего поставщика Linq? Было бы ужасно разрезать строку выражения и таким образом построить мой запрос?

EDIT: Спасибо Кирку за заземление. Я еще раз посмотрел на то, что мне нужно было бы сделать даже для базового парсера SOQL, и это выходит за рамки моих возможностей получить рабочий код приложения, написанный по любому возможному графику. Например, Мне нужно создать список выбора либо из лямбда-выражения метода Select (), либо из списка по умолчанию из всех известных столбцов моего объекта WSDL, задача, о которой я даже не думал (я больше сосредоточился на синтаксическом анализе Where). Я уверен, что есть много других «неизвестных неизвестностей», которые могут превратить это в большое дело. Я нашел несколько ссылок, которые показывают основы написания провайдера Linq, и, хотя все они пытаются упростить его, сейчас это просто невозможно с точки зрения времени. На данный момент я структурирую свой репозиторий, используя именованные методы, которые инкапсулируют именованные запросы (постоянный класс форматируемых строк запроса должен уменьшить количество хлопот в обслуживании). Не идеально, но гораздо более осуществимо. Если и когда провайдер Linq2SOQL начнет работу, будь то собственный или открытый исходный код, мы сможем провести рефакторинг. Графический инструмент или ручное кодирование?

Это довольно сложный / субъективный вопрос, потому что большинство людей решит, основываясь на личных предпочтениях. Это также сильно зависит от качества графического инструмента. В данном случае я хотел бы сосредоточиться только на последней версии библиотеки QT. Я не собираюсь обсуждать, какой метод лучше. Я убежден, что лучший ответ: зависит от проекта.

Мне нужна ссылка на хорошую непредвзятую статью, основанную на опыте после нескольких проектов. Статья должна просто описать компромиссы обоих вариантов