Следует учитывать, что L2S «делает это за вас», создавая объекты в очень большом DBML-файле. Вы можете работать с вашими объектами, создавая частичные классы, но если вы решите попытаться внести какие-либо изменения в dbml-файлы, которые вы ввернули, потому что L2S либо перезапишет ваши изменения, когда он сам себя обновит, либо вам придется реализовать любые изменения вручную в дальнейшем ,
Таким образом, вы застряли, потому что это ужасная идея изменить DBML, но из-за этого существуют ограничения на то, что вы можете сделать с точки зрения именования свойств ваших объектов. Классический пример - использование перечислений, которые хранятся как целые в вашей базе данных. Допустим, у вас есть UserType как перечисление в вашем приложении, в вашей пользовательской таблице вы, вероятно, просто сохраните его как столбец int с именем UserType. Это прекрасно, за исключением того, что когда вы создаете файл DBML, вы отображаете UserType как столбец int ... но если вы действительно хотите, чтобы свойство UserType возвращало перечисление UserType, вы вынуждены либо взломать DBML ... или изменить свои соглашения об именах в ваша база данных соответствует вашему инструменту ORM ... ни один из которых не является хорошим вариантом.
Принимая во внимание, что nHibernate - это просто основанное на XML отображение между ВАШИМИ объектами и ВАШЕЙ базой данных, которое дает вам значительно большую гибкость с точки зрения того, как вы хотите настроить вещи.
еще одна вещь, на которую стоит обратить внимание, это отношения «многие ко многим» и сопоставления таблица-на-подкласс / таблица-на-класс, на которые ссылаются здесь:
http://nhibernate.info/doc/nh/en/index.html
Я не верю, что L2S может обрабатывать отношения между таблицами и подклассами.
Надеюсь, это поможет,
-Макс