Объект Framework & LINQ To SQL - Конфликт интересов?
Нет смысла обновлять ваш интерфейс 10 раз в секунду. Вы не сможете увидеть столько обновлений. Я бы предложил душить их. Вы можете легко сделать все виды регулирования, используя библиотеку Rx.
3 ответа
Стоит отметить, что Платформа Объекта имеет (по крайней мере) три способа быть использованной:
- LINQ к объектам по объектным службам по клиенту объекта
- Объект SQL по объектным службам по клиенту объекта
- Объект SQL с помощью Клиентских объектов команды Объекта (самый подобный классическому ADO.NET)
Клиент объекта в конечном счете выкладывает представление команды ESQL (в канонической, форме агностика базы данных), который Поставщик ADO.NET для определенного RDBMS ответственен за преобразование в хранилище определенный SQL. Это - правильная модель IMHO как за эти годы, много времени инвестировали (и продолжит инвестироваться) в создании великих Поставщиков ADO.NET для каждого хранилища.
Поскольку Платформа Объекта должна работать со многими хранилищами и поэтому многими Поставщиками ADO.NET, там меньше объема для них для легкой оптимизации то, что Клиент Объекта генерирует на на основание хранилища (по крайней мере - это - то, где мы с v1). LINQ команде SQL имел намного меньшую проблему для решения - "работы только с SQL Server" и следовательно мог сделать хранилище определенный материал более легко. Я знаю, что команды EF знают, что существуют случаи, где EF к SQL Server производит TSQL менее эффективно, чем L2S и работает над улучшением этого для V2.
Интересно эта модель позволяет новым возможностям быть добавленными между Клиентом Объекта и Поставщиком ADO.NET для хранилища. Эти "поставщики обертывания" могут добавить услуги, такие как вход, аудит, безопасность, кэширование. Это обсуждено как функция V2 по http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx
При рассмотрении для этого большего изображения, Вы видите, что это было бы ужасно трудно и действительно строго, чтобы попытаться так или иначе модифицировать поколение L2S TSQL в archiecture Платформы Объекта.
Большое различие между Linq to SQL и Entity Framework заключается в том, что EF реализует спецификацию модели данных сущности (EDM), и есть другие продукты, построенные на основе EDM, например данные ADO.NET Службы (также известные как Astoria).
EDM теперь используется для расширения AtomPub в новой спецификации под названием Open Data Protocol (OData http://odata.org/ ), которая используется для стандартизации CRUD поверх REST.
На самом деле EF не генерирует EntitySQL при переводе запросов LINQ. В EF у нас есть представление на основе структуры данных для всех запросов, называемых CQT или каноническими деревьями запросов. И транслятор LINQ, и синтаксический анализатор EntitySQL создают CQT, а остальная часть конвейера трансляции запросов использует CQT (и другие внутренние промежуточные формы), которые после различных преобразований передаются поставщику ADO.NET (как CQT уровня хранилища), который затем отвечает за его перевод на диалект SQL серверной части. Итак, пути: LINQ -> CQT -> SQL или EntitySQL -> CQT -> SQL.