Существует ли DataContext в LINQ к объектам (НЕ Linq-SQL)?
Хорошо, я понял, что проблема была в < Маршрут точный путь = '/' ... когда путь похож на этот "/", чтобы исправить это я изменил:
from: import { BrowserRouter, Route, Switch } from 'react-router-dom'
to: import { HashRouter as Router, Route, Switch } from 'react-router-dom'
and in code below from: <BrowserRouter>
...
</BrowserRouter>
to: <Router>
...
</Router>
Когда я делал приложения через стандартный 'npx create-реакции-app my- app 'этого было достаточно, чтобы добавить < BrowserRouter basename = {process.env.PUBLIC_URL}> но в этом случае это не сработало. может быть, это кому-нибудь поможет.
4 ответа
LINQ к Объектам использует ObjectContext, не DataContext.
Вот краткое описание EF:
LINQ к объектам, классу ObjectContext и модели данных объекта
LINQ к запросам Объектов используют инфраструктуру Объектных служб. Класс ObjectContext является основным классом для взаимодействия с EDM, поскольку CLR возражает. Разработчик создает экземпляр ObjectQuery через ObjectContext. Универсальный класс ObjectQuery представляет запрос, который возвращает экземпляр или набор введенных объектов. Объекты объекта, возвращенные ObjectQuery, прослежены Контекстом объекта и могут быть обновлены при помощи метода SaveChanges.
Это даже не работает тот же путь DataContext в LINQ к SQL. В то время как это верно, что они оба управляют подключением и отслеживают изменения, все же они отличаются по тому, как они моделируют структуры данных и отношения.
Я дал бы плакат того неправильного ответа, который некоторые ослабляют, тем не менее, потому что LINQ к SQL ссылается на "объекты", и кто-то не знакомый с EF мог очень хорошо все еще думать, что они знают то, о чем Вы говорите.
Например:
LINQ к SQL и классу DataContext
DataContext является источником всех объектов, отображенных по соединению с базой данных. Это отслеживает изменения, которые Вы внесли во все полученные объекты и поддерживаете "кэш идентификационных данных", который гарантирует, что объекты, полученные больше чем в один раз, представлены при помощи того же экземпляра объекта.
Это может сбивать с толку.
По-видимому, LinqToEntities использует ObjectContext вместо DataContext.
Это весело, что объектная команда сделала DataContext, и команда данных сделала ObjectContext (и на DataQuery по сравнению с ObjectQuery, и т.д.) "Именование Трудно!"
Обновление, для .net 4 с EF4.1, Вы могли бы также интересоваться DbContext при работе с LinqToEntities.См. также.
Я думаю, что Вы могли бы обращаться к Модели данных Объекта ADO.NET (.edmx файл - сопоставимый с .dbml файлом).
В VS это замечено в Добавить Объекте-> Модель данных Объекта ADO.NET
Существует много этих arbitary различий в синтаксисе. Например, SubmitChanges (L2S) и SaveChanges (L2E). Однако это было бы просто подсказкой различий между этими двумя технологиями.