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

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

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

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

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

Приведи пример такого кода.

Для начала простой кейс как в StackOverflow:
1) Показывать посты по дате добавления
2) Показывать посты по количеству оценок за день (самые популярные)
3) Показывать посты по комментов за день (самые обсуждаемые)
Еще обязательно пейджинг.

Я предполагаю что получится такой набор методов в репозитариях:

IEnumerable<PostData> GetPostsByDate(int start, int pageSize);
IEnumerable<PostData> GetPostsByComments(int start, int pageSize);
IEnumerable<PostData> GetPostsByScore(int start, int pageSize);

Потом внезапно требуется сделать фильтр по тегам, придется править все три метода. В итоге у нас "нижние" слои приложения страдают от изменений деталей представления. Значит расслоение сделано неверно.


В сценарии интернет-магазина или CRM может быть куча фильтров и сортировок и таких методов в репозитарии будет очень много. Поэтому цена изменения станет огромной.