Большая проблема с SubSonic заключается в том, что он генерирует классы из таблиц базы данных, между ними существует взаимно-однозначное соответствие. Это делает классы, генерируемые SubSonic, совершенно неподходящими для использования в качестве бизнес-объектов, потому что это очень привязало бы ваш бизнес-уровень к вашей структуре базы данных. Это плохо (во всяком случае, почти во всех сценариях, которые приходят мне в голову).
SubSonic - это инструмент для запросов и немного больше. Это, безусловно, не ORM.
Имея это в виду, я считаю, что правильным способом создания уровня бизнес-логики является написание собственных бизнес-классов и классов репозитория для управления загрузкой и хранением данных. Но используйте SubSonic только внутри классов Repository для обработки фактического сохранения ваших данных в базе данных.
Если вы будете использовать сгенерированные SubSonic классы в своем проекте, вы обнаружите, что, скорее всего, вы делаете это неправильно, и первое значительное изменение в вашей схеме БД прекрасно это продемонстрирует (или .. не очень).
На самом деле, я бы посоветовал быстро перейти к изучению реального ORM, такого как NHibernate или Entity Framework. Они намного продвигают вас по пути Happy Path, тогда как SubSonic все еще требует, чтобы он сам выполнял большую часть реализации уровня данных.