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

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

S>

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

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

S>>Остался вопрос относительно функций Commit(), Rollback(), BeginTransaction(). Им в репозитории совсем не место. Опять же если вы обратитесь к моему примеру у меня в методе сервиса использовалось 3 репозитория. Чей в таком случае Rollback вызывать? А Commmit. Понятно что для вашего кода это без разницы. Но дизайн кода, что должен думать программист его использующий?
S>>Хорошо бы вынести эти функции в какой-то класс, который абстрагирует нас от DbNorthwind заодно. Но в случае с linq2db это сделать проблематично, т.к. там торчат наружу коллекции сущностей. Зачем-то. Нафига? Никто не знает ответа. Даже автор.

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

S>И чтобы два раза не вставать, вот пример декомпозиции, позволяющий реюзать фильтр пользователей по этажу.

S>

S>IQueryable<UserModel> ApplyFilterByFlat(IQueryable<UserModel> source, int flat)
S>{
S>    return source.Where(u => u.Room.Flat == flat);
S>}
S>

Ничем не отличается от твоего изначального примера. По крайней мере в лучшую сторону. Скорее даже хуже.

S>Теперь этот предикат можно переиспользовать множество раз, комбинируя с другими условиями. И без copy-paste.