Здравствуйте, Козьма Прутков, Вы писали:

КП>Я могу согласиться в отношении соответствия с вами только в одном: на
КП>начальных этапах разработки модель данных соответствует модели
КП>предметной области, так уж процесс устроен, что сначала анализируется
КП>домен (с его моделированием, результаты которого вырастают в модель
КП>предметной области), а потом проектируется база. Но никак не наоборот.
КП>Далее, по мере детализации проектирования, разработки и тем более
КП>поддержки и развития эти модели расходятся.

Ни в коем случае не расходятся, а уточняются детали имплементации. Модели не могут расходится. Если у нас в БД выделена отдельная таблица под хранения связей, а в коде нет соответствующей сущности, то ведь это не означает, что в приведенном тобой примере при изменении данных целевых сущностей (ссылка на 1 со стороны N) содержимое таблицы связей остается неизменным. Оно должно как-то синхронизироваться, либо через триггера, либо через открытие доступа к целевым таблицам посредством лишь SP. Т.е. налицо тонкости реализации, не более того. (точно так же, как данные одной сущности могут хранится в нескольких таблицах при отображении коллекции некой иерархии по наследованию... мне не нравится подобное отображение, но встречается регулярно)

Кстати, в моей модели у нас как отдельная сущность выступает и MasterDetailLink тоже
И предназначен именно для решения такого вопроса, как отделение связей м/у сущностями от способа представления этих связей в персинстентном блоке. Твой пример весьма удачен для моей модели.

Более того, я "агрессивно" занимаюсь кешированием данных, подобное отделение связей в отдельные сущности открывает мне широкий простор для повышения эффективности кеширования без значительных трудозатрат.