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

V>На этом построена архитектура ORM — приложение от него вообще не должно зависеть, оно должно его использовать. Грубо говоря, классы для ORM должны лежать в отдельной сборке с атрибутом internal.
Это опасное заблуждение. Есть такая порода архитекторов, которая искренне полагает, что можно придумать такую архитектуру приложения, которая позволяет хранить данные сегодня в одном XML-файле, завтра — в SQL-ной RDBMS, а послезавтра — в cloud storage в стиле S3. И типа всё, что надо будет для этого сделать — подправить config.xml.
Увы, устройство хранилища невозможно игнорировать. Точно так же, как не получится запустить SQL Server поверх ленточного стримера вместо блочного устройства.
Несмотря на то, что в обоих случаях работа идёт через одну и ту же абстракцию "файл".

V>А может вам стать администраторами баз данных — там SQL, батчи, скорость, ветер, свист в ушах, а? Никаких репозиториев, классов, абстракций.
С чего бы это? Я вам пытаюсь объяснить, что архитектор обязан не только парить в эмпиреях, но и учитывать существенные свойства компонентов системы.
Вот, например, лет двадцать тому назад бытовало мнение, что RPC — это круто. Типа давайте пренебрежём расположением вызываемого компонента. Бёрем, сериализуем сообщение, десериализуем ответ — и вуаля!
Объекты в соседнем процессе так же доступны, как и объекты на другой стороне интернета, и оба доступны так же, как и объекты в нашем собственном адресном пространстве.
А потом внезапно оказывается, что этим пренебрегать никак не получается — потому что объект в нашем адресном пространстве намного доступнее. И приложения, спроектированные без учёта этих особенностей, просто не живут в реальном мире.