Можно ли использовать Entity framework и получать данные не из БД, а из web сервиса (асинхронно) (без LINQ, конечно)?
Вроде как можно.

    MyEntity myEntity = GetMyEntityFromWebApi();
    context.MyEntities.Attach(myEntity);

Есть ли подводные камни данного сценария?
Что можно сделать с сохранением данных? Допусти есть метод SaveMyEntityViaWebApi(MyEntity myEntity).

IB>Есть ли подводные камни данного сценария?
IB>Что можно сделать с сохранением данных? Допусти есть метод SaveMyEntityViaWebApi(MyEntity myEntity).

А зачем в этом случае EF тащить ? Почему бы через интерфейс не сделать

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

IB>Есть ли подводные камни данного сценария?
IB>Что можно сделать с сохранением данных? Допусти есть метод SaveMyEntityViaWebApi(MyEntity myEntity).

Вопрос конечно странный. Путем телепатии сделаю предположение что вам надо брать данные из одного источника и вставить в базу данных? Иначе я не понимаю зачем эти телодвижения.
Eсли так, то зачем Attach, если можно просто Insert.

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

IB>Можно ли использовать Entity framework и получать данные не из БД, а из web сервиса (асинхронно) (без LINQ, конечно)?
IB>Вроде как можно.

IB>

IB>    MyEntity myEntity = GetMyEntityFromWebApi();
IB>    context.MyEntities.Attach(myEntity);
IB>

IB>Есть ли подводные камни данного сценария?
IB>Что можно сделать с сохранением данных? Допусти есть метод SaveMyEntityViaWebApi(MyEntity myEntity).

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

O>А зачем в этом случае EF тащить ? Почему бы через интерфейс не сделать

Требуется разработать приложение на WPF. На данный момент чтение и запись данных напрямую в БД. Но со временем, есть вероятность, что потребуется обращаться к БД через web сервис. Возможно даже потребуется сохранить оба варианта доступа к данным, вариант должен выбираться через конфигурацию.

EntityFramework предоставляет удобный механизм кэширования данных, navigation properties (Reference и Collection (observable)), которые можно биндить в WPF. В случае необходимости перейти на web сервис всё это хочется оставить, а поменять только чтение данных и запись.

Вот и всатаёт вопрос. Хочу использовать EntityFramework, с ним разработка быстрее и качественней. Но возможно ли что-то предпринять сейчас, чтобы потом безболезненно перейти на web сервис, оставив при этом максимум плюшек от EntityFramework, максимально заюзать уже написанный код. Или сразу отказываться от EntityFramework? Может есть какие-то готовые ORM или кэши не завязанные на БД, по функциональности похожие на EntityFramework?

D>Вопрос конечно странный. Путем телепатии сделаю предположение что вам надо брать данные из одного источника и вставить в базу данных? Иначе я не понимаю зачем эти телодвижения.
D>Eсли так, то зачем Attach, если можно просто Insert.

Задача такая

Автор: igor-booch
Дата: 05.05.19

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

O>>А зачем в этом случае EF тащить ? Почему бы через интерфейс не сделать

IB>Требуется разработать приложение на WPF. На данный момент чтение и запись данных напрямую в БД. Но со временем, есть вероятность, что потребуется обращаться к БД через web сервис. Возможно даже потребуется сохранить оба варианта доступа к данным, вариант должен выбираться через конфигурацию.

IB>EntityFramework предоставляет удобный механизм кэширования данных, navigation properties (Reference и Collection (observable)), которые можно биндить в WPF. В случае необходимости перейти на web сервис всё это хочется оставить, а поменять только чтение данных и запись.

IB>Вот и всатаёт вопрос. Хочу использовать EntityFramework, с ним разработка быстрее и качественней. Но возможно ли что-то предпринять сейчас, чтобы потом безболезненно перейти на web сервис, оставив при этом максимум плюшек от EntityFramework, максимально заюзать уже написанный код. Или сразу отказываться от EntityFramework? Может есть какие-то готовые ORM или кэши не завязанные на БД, по функциональности похожие на EntityFramework?

Эти плюшки сделают вашу программу плохо поддерживаемой и в скором времени тормознутой. Не завязывайтесь на сомнительные преимущества. У вас должен быть класс в котором вы реализуете методы типа «дай мне ViewModel, запиши мне ViewModel. И не надо цеплять формы к EF энтитям — это очень плохо попахивает. ViewModel должны быть классами не имеющими к EF никакого близкого отношения, иначе вы базу данных будете дизайнить по типу как выглядит форма — это путь к проклятию тебя коллегами которые будут это поддерживать.

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

IB>Может есть какие-то готовые ORM или кэши не завязанные на БД, по функциональности похожие на EntityFramework?

EntityFramework не завязан на БД.
Создавайте на клиенте(ну т.е. в вашем WPF приложении) in memory DB через Effort и cуйте туда данные из сервиса.

IB>Что можно сделать с сохранением данных? Допусти есть метод SaveMyEntityViaWebApi(MyEntity myEntity).

Переопределяете SaveChanges, где, перед, непосредственно, SaveChanges в вашу базу в памяти, играетесь с ChangeTracker-ом и посылаете в веб-сервис результаты: кто и как поменялся.

Прелесть в том, что вы получаете обычный dbcontext, с которым в вашем приложении можно будет работать привычным образом, делая запросы/фильтры/проекции, navigation properties, tracking changes и вот это вот всё, старый код как работал, так и работает и даже не подозревает, что теперь он общается уже не с БД, а с какой-то проксёй в памяти: для него не изменилось ничего.

Ясное дело, что это всё не бесплатно и влечёт за собой шлейф проблем и граблей, но подумать в эту сторону можно.
Удачи.

D>Эти плюшки сделают вашу программу плохо поддерживаемой и в скором времени тормознутой.

Почему?


D>вы базу данных будете дизайнить по типу как выглядит форма

Если поэтому, то скажу так. У меня в 80% случаев navigation properties хорошо ложатся на форму, при том что структуру БД под формы не подгоняю. В остальных 20%, да, нужны вспомогательные юайные сущности посредники между модельными сущностями (из бд) и формой. Причём эти сущности посредники называю в терминах предметной области, а не безликим словом ViewModel. По поводу поддержки, часто имел проблемы с огромными
вьюмоделями-свалками, либо, наоборот, кучей хитро связанных мелких вьюмоделей. Любая прокладка должна быть функционально оправдана, иначе она приносит только убытки в виде накладных расходов на поддержку.

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

IB>Можно ли использовать Entity framework и получать данные не из БД, а из web сервиса (асинхронно) (без LINQ, конечно)?
IB>Вроде как можно.

IB>

IB>    MyEntity myEntity = GetMyEntityFromWebApi();
IB>    context.MyEntities.Attach(myEntity);
IB>

IB>Есть ли подводные камни данного сценария?
IB>Что можно сделать с сохранением данных? Допусти есть метод SaveMyEntityViaWebApi(MyEntity myEntity).

wcf data services
не это часом нужно?

IB>Вот и всатаёт вопрос. Хочу использовать EntityFramework, с ним разработка быстрее и качественней. Но возможно ли что-то предпринять сейчас, чтобы потом безболезненно перейти на web сервис, оставив при этом максимум
плюшек от EntityFramework, максимально заюзать уже написанный код. Или сразу отказываться от EntityFramework? Может есть какие-то готовые ORM или кэши не завязанные на БД, по функциональности похожие на EntityFramework?


Почему бы не сделать просто интерфейс

ISomethingDataProvider
{
   async Task Update();
   async Task<Some> Get();    
}

и сделать реализацию для EF которая работает с базой, а когда будет сервис сделать реализацию с сервисом.
Причем если будет WCF сервис например или HttpClient то можно будет их родные async методы пробросить не сложно. Не знаю как EF в данном случае будет работать.

Может это создает лишнюю сущность, но DbContext оно как-то ассоциируется с базой данных , а не с произвольным провайдером.

K>wcf data services
K>не это часом нужно?

Сервис будет потребляться web-приложением, возможно java, поэтому завязывать сервис на такую технологию нельзя

O>Почему бы не сделать просто интерфейс
O>

O>ISomethingDataProvider
O>{
O>   async Task Update();
O>   async Task<Some> Get();    
O>}
O>

O>и сделать реализацию для EF которая работает с базой, а когда будет сервис сделать реализацию с сервисом.
O>Причем если будет WCF сервис например или HttpClient то можно будет их родные async методы пробросить не сложно. Не знаю как EF в данном случае будет работать.

O>Может это создает лишнюю сущность, но DbContext оно как-то ассоциируется с базой данных , а не с произвольным провайдером.

Можно сделать так, и получать реализацию ISomethingDataProvider через IoC. Можно без IoC и без интерфейса, просто писать

if (Config.UseService)
{
    return GetSomeFromService();
}
else
{
    return GetSomeFromDb();
}

Не суть, проблема в другом. Если я буду получать данные через EF из БД, то они будут сразу загружаться в контекст EF. Если я буду получать данные через сервис, то нужно дополнительно их грузить в EF. Вопрос можно ли это сделать через метод DbSet.Attach, не приведёт ли это к каким-либо проблемам?
По поводу сохранения, желательно заюзать механизмы EF по отслеживанию изменений и метод DbContext.SaveChanges. Можно ли это как-то сделать получая данные из сервиса?

IB>Не суть, проблема в другом. Если я буду получать данные через EF из БД, то они будут сразу загружаться в контекст EF. Если я буду получать данные через сервис, то нужно дополнительно их грузить в EF. Вопрос можно ли это сделать через метод DbSet.Attach, не приведёт ли это к каким-либо проблемам?
IB>По поводу сохранения, желательно заюзать механизмы EF по отслеживанию изменений и метод DbContext.SaveChanges. Можно ли это как-то сделать получая данные из сервиса?

Мне кажется что DbSet это ближе к Dto чем к логике.
Т.е. я бы пошел по такому пути

namespace BusinessLogic
{
    public class Foo
    {
       ....
    }      
}

namespace WebService.Dto
{
    [DataContract]
    public class FooDto
    {
       ...
    }
}


namespace Database.Dto
{
    public class FooDto
    {
       ...
    }
}

и какую-нибудь фактори для создания BusinessLogic.Foo из вариантов Dto.
А Dto уже специфичные для каждого провайдера.
Они могут и совпадать по полям, но соблазн использовать одну для всех порой в перспективе оказывается не очень удобен, когда неожиданно потребуется различие.

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

K>>wcf data services
K>>не это часом нужно?

IB>Сервис будет потребляться web-приложением, возможно java, поэтому завязывать сервис на такую технологию нельзя

утверждается что ничто не выходит за рамки http, хотя и soap сервис можно из java употребить

O>Мне кажется что DbSet это ближе к Dto чем к логике.
O>Т.е. я бы пошел по такому пути

O>

O>namespace BusinessLogic
O>{
O>    public class Foo
O>    {
O>       ....
O>    }      
O>}

O>namespace WebService.Dto
O>{
O>    [DataContract]
O>    public class FooDto
O>    {
O>       ...
O>    }
O>}


O>namespace Database.Dto
O>{
O>    public class FooDto
O>    {
O>       ...
O>    }
O>}
O>

O>и какую-нибудь фактори для создания BusinessLogic.Foo из вариантов Dto.
O>А Dto уже специфичные для каждого провайдера.
O>Они могут и совпадать по полям, но соблазн использовать одну для всех порой в перспективе оказывается не очень удобен, когда неожиданно потребуется различие.

Я стараюсь не плодить классы, а для каждого термина предметной области использовать 1 класс. Различия можно обыграть через атрибуты, явную реализацию интерфейса, наследование, наследование с рантайм кодогенерацией (как это делает EF). Отдельный класс создаю только в самом крайнем случае, если другие инструменты переменить нельзя, и никогда не создаю отдельный класс от страха, что в будущем без него будет не обойтись.

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

ODATA
https://docs.microsoft.com/ru-ru/dotnet/framework/data/wcf/linq-considerations-wcf-data-services

https://www.odata.org/blog/how-to-use-web-api-odata-to-build-an-odata-v4-service-without-entity-framework/

IB>Вот и всатаёт вопрос. Хочу использовать EntityFramework, с ним разработка быстрее и качественней. Но возможно ли что-то предпринять сейчас, чтобы потом безболезненно перейти на web сервис, оставив при этом максимум плюшек от EntityFramework, максимально заюзать уже написанный код. Или сразу отказываться от EntityFramework? Может есть какие-то готовые ORM или кэши не завязанные на БД, по функциональности похожие на EntityFramework?

Идея хорошая, и посещала уже многих. Но есть серьезное "но". Методы EF — синхронные. Не знаю, может сейчас это исправили. И это ставит(ставило) крест на EF как унифицированном клиенте.
На сколько я помню проблема в кардинальном отличии апи DB от веба. Все реализации IDbConnection, IDbCommand, и т.д. — строго синхронные. И это засада.
Иначе можно было бы еще круче сделать: просто заимплементить провайдер-обертку Db через веб. Да, да, придется как то решать проблему безопасности, масштабирования.. но это проблема имплементации, решаема. А вот с интерфейсами кардинально разными — совсем беда.

Если не смущают коммерческие продукты — смотри
Эти ребята задолго до EF делали отличный ORM.

И кстати, если и в приложении у тебя все завязано на синхронность — то это уже надо как то переделывать. Желательно. На десктопе можно извернутся конечно, и эмулировать синхронность поверх асинхронности, делая всякие фоновые прогрессбары. Но мой опыт уже таков что лучше сразу закладывать асинхронность и на клиенте. Хотя бы потому что асинхронный апи более асбтрактен чем синхронный.

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

K>Здравствуйте, igor-booch, Вы писали:

K>>>wcf data services
K>>>не это часом нужно?

IB>>Сервис будет потребляться web-приложением, возможно java, поэтому завязывать сервис на такую технологию нельзя

K>утверждается что ничто не выходит за рамки http, хотя и soap сервис можно из java употребить

Извиняюсь, сразу не посмотрел. Основано на протоколе OData. Он поддерживается и в java и javascript

IB>>Вот и всатаёт вопрос. Хочу использовать EntityFramework, с ним разработка быстрее и качественней. Но возможно ли что-то предпринять сейчас, чтобы потом безболезненно перейти на web сервис, оставив при этом максимум плюшек от EntityFramework, максимально заюзать уже написанный код. Или сразу отказываться от EntityFramework? Может есть какие-то готовые ORM или кэши не завязанные на БД, по функциональности похожие на EntityFramework?

_>Идея хорошая, и посещала уже многих. Но есть серьезное "но". Методы EF — синхронные. Не знаю, может сейчас это исправили. И это ставит(ставило) крест на EF как унифицированном клиенте.

Насколько я понимаю, ты описываешь следующую проблему. На декстопе я могу

1) считать данные
2) показать форму
пользователь вводит данные
3) записать данные

1 и 2 я могу делать параллельно, то есть считывать данные асинхронно.
1 и 3 я могу сделать в одном контексте

В веб приложении считывать данные и одновременно показывать форму затруднительно.
В веб приложении каждый запрос делается в отдельном контексте, поэтому 1 и 3 будут в разных контекстах (решается через отсоединённый сущности).

Правильно?

В моём случае веб сервис может потребоваться в первую очередь для мобильного приложения на Xamarin. В нём можно сделать как на десктопе.

PS: в EF6 появились асинхронные методы