Продолжение в сочетании с ActiveRecord какие-либо глюки?
Если Вы хотите, чтобы Ваш вид был доступен для людей с и без нарушений, а также внешние системы, то да, необходимо определенно удостовериться, что Вы производите допустимый HTML.
легко протестировать Ваш HTML с автоматические блоки проверки допустимости .
я добавлю к тому, что Mike Edwards сказал о легальных разветвлениях, и напомните Вам, что у Вас есть моральное обязательство также:)
2 ответа
Отказ от ответственности: я сопровождаю сиквел.
Сиквел легко использовать вместе с ActiveRecord или вместо него при использовании Rails. Вам нужно настроить соединение с базой данных вручную, но в остальном использование аналогично. Файлы ваших моделей Sequel находятся в app / models и работают аналогично моделям ActiveRecord.
Установка соединений с базой данных не утомительна, обычно требуется одна строка в environment.rb, чтобы требовать продолжения, и строку в каждом файле среды (разработка .rb, test.rb, production.rb), чтобы сделать что-то вроде:
DB = Sequel.connect (...)
Так что это утомительно, только если вы считаете утомительным 4 строки кода установки.
Использование необработанный SQL обычно не является проблемой, если вы не нацелены на несколько баз данных. Основная причина избегать этого - повышенная многословность. Sequel поддерживает использование необработанного SQL по крайней мере так же легко, как ActiveRecord, но случаи, когда вам нужно использовать необработанный SQL, как правило, довольно редки в Sequel.
Кстати, Sequel поставляется с несколькими плагинами проверки. Плагин validation_class_methods похож на проверки ActiveRecord с использованием методов класса. Плагин validation_helpers имеет более простую реализацию с использованием методов уровня экземпляра, но оба могут делать примерно одно и то же.
Наконец, я скажу, что если у вас уже есть рабочий код ActiveRecord, который делает то, что вы хотите, вероятно, это не стоит усилий. чтобы перенести код в Sequel, если вы не планируете добавлять функции.
Плагин validation_class_methods похож на проверки ActiveRecord с использованием методов класса. Плагин validation_helpers имеет более простую реализацию с использованием методов уровня экземпляра, но оба могут делать примерно одно и то же.Наконец, я скажу, что если у вас уже есть рабочий код ActiveRecord, который делает то, что вы хотите, вероятно, это не стоит усилий. чтобы перенести код в Sequel, если вы не планируете добавлять функции.
Плагин validation_class_methods похож на проверки ActiveRecord с использованием методов класса. Плагин validation_helpers имеет более простую реализацию с использованием методов уровня экземпляра, но оба могут делать примерно одно и то же.Наконец, я скажу, что если у вас уже есть рабочий код ActiveRecord, который делает то, что вы хотите, вероятно, это не стоит усилий. чтобы перенести код в Sequel, если вы не планируете добавлять функции.
Лично я бы не стал этого делать. Для начала, простое управление подключением, более или менее вручную, было бы утомительно. Я был бы более склонен, если бы я чувствовал, что Sequel был более сильным вариантом, отложить до Rails 3.0 (или, возможно, начать разработку против Edge Rails), где должно быть довольно легко переключать ORM, если Иегуда и компания делают свои вещи правильно . По крайней мере, намного больше, чем сейчас.
Это был взгляд DHH на эту тему (я не говорю, что это следует воспринимать как евангельскую истину, ум, но это, так сказать, из уст лошади ):
Но разве Sql не грязный?
С тех пор, как программисты начали слой объектно-ориентированных систем сверху реляционных баз данных, они боролся с вопросом, как глубоко запустить абстракцию. Некоторые объектно-реляционные картографы стремятся полностью искоренить использование SQL, стремление к объектно-ориентированной чистоте форсирование всех запросов через другой объектно ориентированный объект слой.
Active Record не поддерживает. Он был построен на том, что SQL не является ни ни грязно, ни плохо, просто многословно в тривиальные случаи. Основное внимание уделяется устранение необходимости иметь дело с многословие в этих тривиальных случаях, но сохранить выразительность для сложные запросы - тип SQL был созданы, чтобы обращаться с ними элегантно.
Следовательно, вы не должны чувствовать себя виноватыми когда вы используете find_by_sql () для обработки либо узкие места в производительности, либо запросы. Начните с использования объектно-ориентированный интерфейс для продуктивность и удовольствие, и падение под поверхностью для близкий к металлу опыт, когда вы необходимо.
(Цитата была найдена здесь , исходный текст находится на стр. 334 из AWDRWR , книги «гамак»).
Думаю, это разумно.
Мы говорим о чем-то, с чем не может справиться find_by_sql ? Или мы говорим о сложных вещах, не связанных с SELECT, с которыми execute не может справиться?
Какие примеры мы могли бы посмотреть?