Здравствуйте, A-Myth, Вы писали:

AM>К чему этот вопрос: мне сейчас надо накидать прототип, который возможно перерастёт в большой проект (а возможно и нет). Нужен ORM. Хотелось бы, конечно, плюшек в виде lazy loading и change tracking (т.к. неизвестно куда потом требования угуляют), но и без них можно обойтись.
AM>Так же важен момент быстрого вхождения средних (не совсем бестолковых, но и не "10x") разработчиков.
AM>Хотелось бы надёжную штуковину, которая бы 3-4 года ещё была актуальна и "в струе" дотнета.
AM>База планируется средней нагруженности — будут блобы, файлы-документы, сотни пользователей, планировщики и т.д.
AM>Что бы мне такое выбрать, чтобы не очень промахнуться?

Не очень понимаю где будет проблема. Если код ORM полностью скрыт от остальной программы за слоем репозиториев (тут важное уточнение: многие под репозиториями понимают почему-то шлюзы к таблицам), то сменить его будет просто или вообще использовать SQL и ADO.NET.

На практике, увы, люди таскают классы-маппинги ORM (хоть POCO, хоть нет) по всей системе, пытаются вывернуть ORM наизнанку, заставляя внешний код вникать в детали того, как эта конкретная ORM работает. Сам так делал пока не вырос. В результате, их код очень цепко связан с конкретной ORM.