Сообщение Re[8]: Альтернативы EF Core от 17.08.2017 17:24
Изменено 17.08.2017 19:11 Nikita Lyapin
Re[8]: Альтернативы EF Core
Уже гораздо лучше, чем у @Danchik. Самое главное автору данного кода пришло осознание, что запрос GetUsersOnTheFlat может встречаться более чем в одном сервисе. И нужно куда-то его вынести, чтобы не делать copy/past.
Repository как раз для этого и предназначен.
Причем в моем представлении этот запрос гораздо более сложный может быть c джойнами на организацию, на здание, на информацию по зданию и т.п.
Остался вопрос относительно функций Commit(), Rollback(), BeginTransaction(). Им в репозитории совсем не место. Опять же если вы обратитесь к моему примеру у меня в методе сервиса использовалось 3 репозитория. Чей в таком случае Rollback вызывать? А Commmit. Понятно что для вашего кода это без разницы. Но дизайн кода, что должен думать программист его использующий?
Хорошо бы вынести эти функции в какой-то класс, который абстрагирует нас от DbNorthwind заодно. Но в случае с linq2db это сделать проблематично, т.к. там торчат наружу коллекции сущностей. Зачем-то. Нафига? Никто не знает ответа. Даже автор.
Поэтому в сервисах будет DbNorthwind и меньший уровень абстракции, чем мог бы быть.
P.S. Обратите внимание как @Danchik был вынужден упростить код моей функции. У него простая вставка в User. Это как бы намекает какой из подходов используется в реальных боевых проектах, а какой в учебных.
Repository как раз для этого и предназначен.
Причем в моем представлении этот запрос гораздо более сложный может быть c джойнами на организацию, на здание, на информацию по зданию и т.п.
Остался вопрос относительно функций Commit(), Rollback(), BeginTransaction(). Им в репозитории совсем не место. Опять же если вы обратитесь к моему примеру у меня в методе сервиса использовалось 3 репозитория. Чей в таком случае Rollback вызывать? А Commmit. Понятно что для вашего кода это без разницы. Но дизайн кода, что должен думать программист его использующий?
Хорошо бы вынести эти функции в какой-то класс, который абстрагирует нас от DbNorthwind заодно. Но в случае с linq2db это сделать проблематично, т.к. там торчат наружу коллекции сущностей. Зачем-то. Нафига? Никто не знает ответа. Даже автор.
Поэтому в сервисах будет DbNorthwind и меньший уровень абстракции, чем мог бы быть.
P.S. Обратите внимание как @Danchik был вынужден упростить код моей функции. У него простая вставка в User. Это как бы намекает какой из подходов используется в реальных боевых проектах, а какой в учебных.
Re[8]: Альтернативы EF Core
Уже гораздо лучше, чем у @Danchik. Самое главное автору данного кода пришло осознание, что запрос GetUsersOnTheFlat может встречаться более чем в одном сервисе. И нужно куда-то его вынести, чтобы не делать copy/past.
Repository как раз для этого и предназначен.
Причем этот запрос гораздо более сложный может быть c джойнами на организацию, на здание, на информацию по зданию и т.п.
Остался вопрос относительно функций Commit(), Rollback(), BeginTransaction(). Им в репозитории совсем не место. Опять же если вы обратитесь к моему примеру у меня в методе сервиса использовалось 3 репозитория. Чей в таком случае Rollback вызывать? А Commmit? Понятно что для вашего кода это без разницы. Но дизайн кода... Что должен думать программист его использующий?
Хорошо бы вынести эти функции в какой-то класс, который абстрагирует нас от DbNorthwind заодно. Но в случае с linq2db это сделать проблематично, т.к. там торчат наружу коллекции сущностей. Зачем-то. Нафига? Никто не знает ответа. Даже автор.
Поэтому в сервисах будет DbNorthwind и меньший уровень абстракции, чем мог бы быть.
P.S. Обратите внимание как @Danchik был вынужден упростить код моей функции. У него простая вставка в User. В то время как у меня была работа с тремя репозиториями. Это как бы намекает какой из подходов используется в реальных боевых проектах, а какой в учебных.
Repository как раз для этого и предназначен.
Причем этот запрос гораздо более сложный может быть c джойнами на организацию, на здание, на информацию по зданию и т.п.
Остался вопрос относительно функций Commit(), Rollback(), BeginTransaction(). Им в репозитории совсем не место. Опять же если вы обратитесь к моему примеру у меня в методе сервиса использовалось 3 репозитория. Чей в таком случае Rollback вызывать? А Commmit? Понятно что для вашего кода это без разницы. Но дизайн кода... Что должен думать программист его использующий?
Хорошо бы вынести эти функции в какой-то класс, который абстрагирует нас от DbNorthwind заодно. Но в случае с linq2db это сделать проблематично, т.к. там торчат наружу коллекции сущностей. Зачем-то. Нафига? Никто не знает ответа. Даже автор.
Поэтому в сервисах будет DbNorthwind и меньший уровень абстракции, чем мог бы быть.
P.S. Обратите внимание как @Danchik был вынужден упростить код моей функции. У него простая вставка в User. В то время как у меня была работа с тремя репозиториями. Это как бы намекает какой из подходов используется в реальных боевых проектах, а какой в учебных.