Micro ORM - поддержание ваших строк SQL-запроса
Я не буду вдаваться в подробности, почему я изучаю использование Micro ORM на данном этапе - за исключением того, что я чувствую себя бессильным, когда использую полномасштабный ORM. В фоновом режиме происходит слишком много вещей, которые происходят автоматически, и не все из них - лучший выбор. Я был вполне готов вернуться к необработанному доступу к базе данных, но узнал о трех новых парнях на блоке: Dapper, PetaPoco и Massive. Поэтому я решил применить низкоуровневый подход к домашнему проекту. Это не актуально, но пока я использую PetaPoco.
В любом случае, У меня возникли проблемы с принятием решения о том, как поддерживать строки SQL, которые я буду использовать с более высоких уровней. Я могу придумать три основных решения:
Распространяйте SQL-запросы везде, где они мне нужны. Это метод с наименьшей нагрузкой на инфраструктуру. Однако он страдает как с точки зрения ремонтопригодности, так и с точки зрения тестируемости.
Ограничьте использование запросов некоторыми классами обслуживания. Это помогает поддерживать ремонтопригодность, все еще недостаточно инфраструктуры, которую мне нужно реализовать. Также возможно построить эти классы обслуживания так, чтобы их было легко смоделировать для целей тестирования.
Подготовьте несколько классов, чтобы сделать систему в некоторой степени гибкой. Я пошел по этому пути. Я реализовал интерфейс репозитория и класс репозитория, зависящий от базы данных. Я также создал несколько крошечных интерфейсов для захвата SQL-запросов, которые можно передать в мой репозиторий. s GetMany () метод. Все запросы сейчас реализованы как отдельные классы, и мне, вероятно, понадобится немного больше интерфейса вокруг этого, чтобы добавить некоторый уровень независимости базы данных - и, возможно, для некоторой гибкости в оформлении запросов в страничные и отсортированные запросы (опять же, это также сделало бы они немного более гибкие в работе с различными базами данных)
Что меня больше всего беспокоит сейчас, так это то, что я вступил на скользкий путь написания всех функций, необходимых для полномасштабного ORM, но плохо. Например, сейчас кажется разумным, что я пишу или нахожу библиотеку для преобразования вызовов linq в операторы SQL, чтобы я мог легко массировать свои запросы или писать расширители, которые могут украсить любой запрос, который я ему передаю, и т. Д. Но это большой задача, и уже выполняется большими парнями, так что я сопротивляюсь желанию пойти туда. Я также хочу сохранить контроль над тем, какие запросы я отправляю в базу данных, явно записывая их.
Итак, что предлагается? Мне выбрать вариант №2 или попытаться наткнуться на вариант №3? Я уверен, что не смогу показать никому код, написанный в первом варианте, не краснея. Вы можете порекомендовать какой-либо другой подход?
РЕДАКТИРОВАТЬ: После того, как я задал вопрос, я понял, что есть еще один вариант, несколько ортогональный этим трем параметрам: хранимые процедуры. Кажется, есть несколько преимуществ в том, чтобы помещать все ваши запросы в базу данных в виде хранимых процедур. Они хранятся в центральном месте и не распространяются по коду (хотя обслуживание является проблемой - параметры могут не синхронизироваться). Зависимость от диалекта базы данных решается автоматически: если вы перемещаете базы данных, вы переносите все свои хранимые процедуры, и все готово. И есть также преимущества безопасности.
С опцией хранимой процедуры альтернативы 1 и 2 кажутся немного более подходящими. Кажется, недостаточно сущностей, чтобы гарантировать вариант 3, но все же можно отделить команды вызова процедур от кода доступа к базе данных.
Я реализовал вариант 3 без хранимых процедур и вариант 2 с хранимыми процедурами, и он похоже, что последний мне больше подходит (на случай, если кто-то интересуется исходом вопроса).