Хм ... ну ... как бы это сказать ...
В настоящее время (как и сейчас) я прилагаю все усилия, чтобы заменить SubSonic на PetaPoco . Я полагаю, это что-то говорит.
Это не значит, что SubSonic был плохим, но он не очень хорошо подходил для моего развития. И для людей, которые хотят принять его на данный момент, кажется очень важным отметить абсолютное отсутствие активности в проекте.
Во-первых, самой большой причиной, по которой SubSonic мне не подошел, был LINQ.
Есть уверенность в том, что компилятор проверяет все свойства, чтобы быть уверенным. Однако на практике он просто не подходил для запросов.
Если вы очень внимательно относитесь к использованию классов для каждой таблицы и ActiveRecord, я думаю, это нормально. Но всякий раз, когда нам приходилось делать какие-либо запросы помимо этого (что-либо, включающее несколько таблиц или что-либо, кроме простых предложений where), это был кошмар. Ассоциации нельзя использовать непосредственно в запросе SubSonic LINQ, как они могут быть в EF или nHibernate, что, вероятно, было самой большой проблемой.
Например, такой запрос не будет работать в SubSonic, но в EF:
db.Accounts.Where(a => a.OwningUser.Email != null);
В конечном итоге я либо совершал много обращений к базе данных, чтобы собрать результат, либо использовал класс CodingHorror SubSonic для выполнения запросов непосредственно с SQL, и не мог просто материализовать их как POCO. (опять же, выходя за рамки простого класса на таблицу).
Я также обнаружил, что каждый поставщик LINQ поддерживает разные наборы операций, и иногда одна и та же логическая операция будет иметь немного другой синтаксис и использование между поставщиками. Это делает написание большинства запросов очень трудоемким и подверженным ошибкам. Поставщик SubSonic LINQ не лишен причудливых и недооцененных возможностей. Он не имеет ничего общего с Linq-2-SQL, Entity Framework или LINQ, чтобы nHibernate его условия поддерживаемых операций, удобство использования или скорость выполнения (будьте готовы изучить новые способы написания объединений в LINQ только для SubSonic - и будьте готовы к тому, что некоторые обычные операции будут просто невозможны с поставщиком LINQ от SubSonic, несмотря на то, что в течение года были известны ошибки ).
В дополнение к снижению производительности легко забыть, что код LINQ, который вы пишете, очень зависит от поставщика. ANSI SQL является далеко более стандартным и кросс-совместимым, чем LINQ.
LINQ также соблазнил меня возможностями повторного использования кода с помощью таких методов, как Спецификации, но реализовать их было далеко не просто, а конечный результат даже близко не стоил усилий. Мостовые препятствия, с которыми я столкнулся здесь, были в основном связаны с тем, что поставщик LINQ от SubSonic не поддерживал ассоциации.
Возможности SubSonic вне LINQ, на мой взгляд, были в лучшем случае посредственными (на мой взгляд).
Во-вторых, важно знать, что по всем параметрам SubSonic не является активным проектом.
Первоначальный создатель SubSonic, Роб Конери, больше не работает над проектом. Последний коммит Роб сделал в июле 2010 года .
Последняя фиксация проекта вообще была 3 месяца назад , , несмотря на почти 100 нерешенных вопросов . И, насколько я могу судить, не было ни одного релиза, даже незначительного выпуска, так как Роб прекратил работать над SubSonic (хотя люди, все еще болтающиеся вокруг проекта, говорили о релиз более полугода ).
Группа Google для SubSonic раньше была активна, но в наши дни не так много. А также официальный сайт проекта SubSonic некоторое время был желтым скринингом смерти (у сайта больше нет желтых экранов).
Новая проблема в доступе к данным - это микро-ORM. Создатель SubSonic, на самом деле, отчасти начал эту тенденцию с Massive , за которым вскоре последовала команда StackExchange, выпустившая Dapper , а затем PetaPoco . Есть еще пара тоже. И хотя мы отказываемся от небольшой проверки компилятором, имея фрагменты SQL в нашей базе кода, я считаю, что микро-ORM гораздо лучше подходит моему стилю разработки, чем SubSonic.
Мой опыт (хотя и ограниченный) с nHibernate заключался в том, что он является чрезмерно сложным для большинства сценариев, и даже когда это уместно, он абсолютно убил время запуска моего приложения. Была также высокая кривая обучения (которую вы, возможно, уже прошли), но также есть несколько способов сделать это ... в основном все ... так что это просто добавляет еще много решений в мой процесс (замедляя меня).
С PetaPoco я могу написать знакомый SQL - я быстр и достаточно хорош в этом - и материализовать их в POCO, что, я знаю, что, черт возьми, делать тут же. Небольшая разбросанность архитектуры и организации, а также автоматизированное интеграционное тестирование, и я совсем не чувствую себя грязным из-за внедрения битов SQL.
О, и я полагаю, последнее - SubSonic - далеко не самый быстрый способ получения данных. Может быть, не важно, но это оказалось для нас.
В заключение (простите за стену текста):
Нельзя сказать, что SubSonic плох в каком-то абсолютном смысле. Похоже, он совсем не подходил к тому, как я пытался его использовать, и во многом это связано с тем, что LINQ по-прежнему является утечкой абстракции, и она утечка по-разному, чем я привык.
Тот факт, что усилия по разработке практически отсутствуют, - это хорошо и плохо. Хорошо, он стабилен и в некотором смысле считается «законченным». Плохо, ему не хватает функций, возможно, есть некоторые ошибки, и он не лучший исполнитель - и никто не работает над этим.