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

Serg>>Ты неправильно мня понял. Я как раз против универсального GetUsersOnTheFlat. Одно дело, когда нужно получить список пользователей на этаже для того, чтобы отправить им почтовое уведомление, а другое дело, когда нужно начислить им компенсацию за не работающий лифт. Или уволить всех скопом.
Serg>>Если сделать универсальный метод, возвращающий коллекцию пользователей с полным набором атрибутов, то работать он будет везде неэффективно.

Вот на это что скажешь (см. выше)?

Serg>>С linq2db можно не бояться джоинов, поскольку он автоматически генерирует схему, включающую и описания таблиц, и связи между ними для легкой навигации parent->child и обратно.
Serg>>И тогда джоин на здание или организацию будет выполняться простым обращением к свойству.

Serg>>

Serg>>_db.User.Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })
Serg>>

S>Зачем условие опустил?

Добавил условие. Что это меняет?

    _db.User.Where(u => u.Room.Flat == flat).Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })

Показать переиспользование бизнес логики условий? Вот:

var users = _db.User;

users = ApplyFilterByFlat(users, flat);

users = ApplyRowLevelSecurity(users);

users = ExcludeVipUsers(users);

return users.Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })

Если озаботиться эстетикой, можно навернуть поверх методы-расширения и организовать method chaining. Но это уже мелочи, не влияющие на принципиальную возможность.

S>Как правило joins и условия являются важной частью бизнес-логики. Достаточно в репозитории сделать приватный метод, который будут использовать публичные, а также будут делать проекции. Вовсе не обязательно ради проекций дублировать по всем сервисам эту бизнес-логику.

Я уже второй пост пишу о том, как в linq2db избавиться от дублирования логики джоинов и условий.

Serg>>Торчат наружу не коллекции, а IQueriable интерфейсы к таблицам, что позволяет гибко извлекать ровно те данные, которые нужны для конкретного сервиса.
S>А должно торчать DbNorthwind.Query<User>, DbNorthwind.Query<Organization>, DbNorthwind.Query<Message>. Понятна разница?

Разницу вижу, но не в пользу твоего варианта. Зачем мне целый User, если мне нужен только электронный адрес?