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

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

Serg>>>Ты неправильно мня понял. Я как раз против универсального GetUsersOnTheFlat. Одно дело, когда нужно получить список пользователей на этаже для того, чтобы отправить им почтовое уведомление, а другое дело, когда нужно начислить им компенсацию за не работающий лифт. Или уволить всех скопом.
Serg>>>Если сделать универсальный метод, возвращающий коллекцию пользователей с полным набором атрибутов, то работать он будет везде неэффективно.
S>Вот на это что скажешь (см. выше)?
Я не вижу здесь каких либо препятствий. Это издержки примера, придуманного за 2 минуты. Понятно, что если бы я начал тюнить код, то вытаскивал бы не пользователя, а string с email. Хотя в общем и целом лично я не склонен преувеличивать нагрузку от вытаскивания всей сущности целиком. Да, иногда это действительно заметно и тут надо тюнить. Но в большенстве случаев скорее наоброт ты за один раз вытаскиваешь сущность, части которой потом ниже используешь. Может сложится обратная ситуация, когда ты вместо этого постоянно дергаешь базу ради разных частей одной сущности. Одним словом It depends.

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


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

S>

S>var users = _db.User;

S>users = ApplyFilterByFlat(users, flat);

S>users = ApplyRowLevelSecurity(users);

S>users = ExcludeVipUsers(users);

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

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

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

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

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

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

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