Поскольку вы, похоже, имеете довольно прямое отображение из класса в таблицу, Linq to SQL должен выполнить свою задачу без каких-либо трудностей. Это позволило бы вам начать работу очень быстро, без первоначальной работы по сопоставлению домена вручную с базой данных.
Альтернативой может быть использование NHibernate + Fluent NHibernate и его функции AutoMapping, но имейте в виду, что Fluent NHibernate AutoMapping еще довольно молод.
Я не совсем уверен, что понимаю, как вы хотите, чтобы ваши сущности выглядели, но с Linq to SQL вы получите большой сгенерированный беспорядок, который вы затем сможете расширить с помощью частичных классов. NHibernate позволяет вам создавать классы так, как вы хотите, и не генерирует ничего для вас из коробки. Вы могли бы использовать классы POCO с Linq to SQL, но это лишило бы всех преимуществ использования Linq to SQL, а не NHibernate.
Что касается шаблона репозитория и использования универсального репозитория, то это может быть сделано весьма неплохо и с Linq to SQL, а не только с NHibernate. На мой взгляд, это одна из приятных вещей в Linq to SQL.
Если вам, вероятно, понадобится поддержка других баз данных, кроме SQL Server, NHibernate является единственным выбором. Однако, если это, вероятно, не будет проблемой, я бы рекомендовал не использовать это в качестве основного фактора при выборе. Другие факторы, вероятно, будут влиять на ваш проект больше.
Вывод:
В общем, я бы рекомендовал Linq для SQL, в этом случае, так как это позволило бы вам быстро начать работу и этого достаточно для ваших нужд. Предварительным условием для этого является то, что у вас нет проблем с мыслью о создании грязного кода в вашем домене, и вы совершенно уверены, что в будущем не будет необходимости поддерживать другие базы данных. В противном случае я бы порекомендовал NHibernate, так как это действительно потрясающий ORM.