Id & amp; Свойство Type не связано, когда Type не является виртуальным [duplicate]

Question

Id & amp; Свойство Type не связано, когда Type не является виртуальным [duplicate]

для (var s of myStringArray) {

(Непосредственно отвечая на ваш вопрос: теперь вы можете!) [/ g10]

Большинство других ответов верны, но они не упоминают (по состоянию на это письмо), что ECMA Script & nbsp; 6 & nbsp; 2015 приносит новый механизм для выполнения итерации цикла for..of.

Этот новый синтаксис является самым элегантным способом перебора массива в javascript (так как вам не нужен индекс итерации), но он пока еще не поддерживается браузерами.

В настоящее время он работает с Firefox 13+, Chrome 37+ и не работает с другими браузерами (см. ниже раздел браузера). К счастью, у нас есть компиляторы JS (такие как Babel ), которые позволяют нам использовать функции следующего поколения.

Он также работает на узле (я тестировал его на версии 0.12.0)

Итерирование массива

// You could also use "let" instead of "var" for block scope.
for (var letter of ["a", "b", "c"]) { 
   console.log(letter); 
}

Итерирование массива объектов

var band = [
  {firstName : 'John', lastName: 'Lennon'}, 
  {firstName : 'Paul', lastName: 'McCartney'}
];

for(var member of band){
  console.log(member.firstName + ' ' + member.lastName); 
}

Итерация генератора:

(пример извлечен из https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of )

function* fibonacci() { // a generator function
  let [prev, curr] = [1, 1];
  while (true) {
    [prev, curr] = [curr, prev + curr];
    yield curr;
  }
}

for (let n of fibonacci()) {
  console.log(n);
  // truncate the sequence at 1000
  if (n >= 1000) {
    break;
  }
}

Таблица совместимости: http://kangax.github.io/es5-compat-table/es6/#For..of loop

Spec: http://wiki.ecmascript.org/doku.php?id=harmony:iterators

}

189

entity-framework

задан jps 7 January 2016 в 12:31

5 ответов

Обычно довольно типично определять навигационные свойства виртуальной модели. Когда свойство навигации определяется как виртуальное, оно может воспользоваться некоторыми функциональными возможностями Entity Framework. Наиболее распространенным является ленивая загрузка.

Lazy loading - хорошая функция многих ORM, потому что она позволяет динамически получать доступ к связанным данным из модели. Он не будет излишне запрашивать связанные данные до тех пор, пока он не будет фактически доступен, что уменьшит предварительный запрос данных из базы данных.

Из книги «ASP.NET MVC 5 с Bootstrap и Knockout .js "

12

ответ дан Hassan Rahman 24 August 2018 в 01:01

Ключевое слово virtual в C # позволяет переопределить метод или свойство дочерними классами. Для получения дополнительной информации см. документацию MSDN по ключевому слову «virtual»

ОБНОВЛЕНИЕ: Очевидно, что мой ответ не соответствует тому, что ожидалось, учитывая обстоятельства вопроса , но я оставлю его здесь для тех, кто ищет простой ответ на оригинал , заданный без описательного вопроса.

72

ответ дан M.Babcock 24 August 2018 в 01:01

1

– mmcrae 24 June 2015 в 21:42

Я понимаю разочарование OPs, это использование виртуального не для шаблонной абстракции, для которой эффективный виртуальный модификатор defacto эффективен.

Если кто-то все еще борется с этим, я бы предложил свою точку зрения, поскольку я стараюсь, чтобы простые решения и жаргон были минимальными:

Entity Framework в простой части использует ленивую загрузку, что эквивалентно подготовке чего-то для будущего исполнения.

В Entity Framework использование свойства виртуальной навигации позволяет вам обозначить его как эквивалент NULL-ключа в SQL. Вы не должны с радостью присоединяться к каждой таблице с ключами при выполнении запроса, но когда вам нужна информация, она становится ориентированной на спрос.

Я также упомянул об ошибке, поскольку многие свойства навигации не актуальны в первую очередь. т. е. в сценарии «клиент / заказ» вам не нужно ждать момента, когда заказ будет обработан для создания клиента. Вы можете, но если у вас был многоэтапный процесс для достижения этого, вы можете обнаружить необходимость сохранения данных клиента для последующего завершения или для развертывания в будущих заказах. Если были реализованы все свойства nav, вам нужно будет установить каждый внешний ключ и реляционное поле в файле save. Это действительно просто возвращает данные в память, что наносит ущерб роли настойчивости.

Итак, хотя это может показаться загадочным в фактическом выполнении во время выполнения, я нашел, что лучшим правилом для использования будет: если вы выводите данные (чтение в модель просмотра или модель Serializable) и нужны значения перед ссылками, не используйте виртуальные; Если ваша область данных собирает данные, которые могут быть неполными или необходимость поиска и не требует, чтобы каждый параметр поиска был завершен для поиска, код будет хорошо использовать ссылку, аналогичную использованию свойств значения nullable value int? длинный?. Кроме того, абстрагирование вашей бизнес-логики из вашей коллекции данных до тех пор, пока она не будет введена в нее, имеет много преимуществ в производительности, аналогично созданию экземпляра объекта и его запуску при нулевом значении. Entity Framework использует много отражения и динамики, которые могут ухудшить производительность, и необходимость иметь гибкую модель, которая может масштабироваться для обеспечения, имеет решающее значение для управления производительностью.

Для меня это всегда имело больше смысла, чем используя перегруженный технический жаргон, например, прокси, делегаты, обработчики и т. д. Как только вы нажмете свой третий или четвертый язык программирования, он может запутаться с ними.

19

ответ дан Nathan Teague 24 August 2018 в 01:01

В контексте EF маркировка свойства как виртуального позволяет EF использовать ленивую загрузку для ее загрузки. Для ленивой загрузки на работу EF должен создать прокси-объект, который переопределяет ваши виртуальные свойства реализацией, которая загружает объект, на который ссылается, когда он впервые обращается. Если вы не отмечаете свойство как виртуальное, тогда ленивая загрузка с ним не будет работать.

1

ответ дан Shakeer Hussain 24 August 2018 в 01:01

Другие вопросы по тегам:

entity-framework

Похожие вопросы:

score 216 · Accepted Answer

Это позволяет Entity Framework создавать прокси-сервер вокруг виртуального свойства, чтобы свойство могло поддерживать ленивую загрузку и более эффективное отслеживание изменений. См. . Какие эффекты могут иметь ключевое слово virtual в Entity Framework 4.1. Код POCO First? для более подробного обсуждения.

Изменить, чтобы уточнить «создать прокси-сервер»: «создайте прокси-сервер». Я имею в виду конкретно то, что делает Entity Framework. Для платформы Entity Framework ваши свойства навигации должны быть помечены как виртуальные, чтобы поддерживать ленивую загрузку и эффективное отслеживание изменений. См. Требования к созданию прокси POCO . Entity Framework использует наследование для поддержки этой функции, поэтому она требует, чтобы определенные свойства были помечены как виртуальные в вашем базовом классе POCOs. Он буквально создает новые типы, которые происходят из ваших типов POCO. Таким образом, ваш POCO действует как базовый тип для динамически созданных подклассов Entity Framework. Это то, что я имел в виду под «созданием прокси-сервера».

Динамически созданные подклассы, созданные Entity Framework, становятся очевидными при использовании Entity Framework во время выполнения, а не во время статической компиляции. И только если вы включите ленивые функции загрузки или изменения отслеживания Entity Framework. Если вы решите никогда не использовать ленивые функции отслеживания загрузки или изменения в Entity Framework (который не является стандартным), вам не нужно объявлять какие-либо свойства навигации как виртуальные. Затем вы отвечаете за загрузку этих свойств навигации самостоятельно, используя то, что Entity Framework называет «нетерпеливой загрузкой», или вручную извлекает связанные типы для нескольких запросов к базе данных. Однако вы можете и должны использовать ленивые функции загрузки и изменения отслеживания для ваших свойств навигации во многих сценариях.

Если вы должны были создать отдельный класс и пометить свойства как виртуальные, а просто создать и использовать экземпляры этих классов в своем собственном приложении, полностью вне сферы действия Entity Framework, то ваши виртуальные свойства не будут Я ничего не выиграю.

Изменить, чтобы описать, почему свойства будут помечены как виртуальные

. Такие свойства, как:

 public ICollection<RSVP> RSVPs { get; set; }

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

//Internally the code looks more like this:
public ICollection<RSVP> get_RSVPs()
{
    return _RSVPs;
}

public void set_RSVPs(RSVP value)
{
    _RSVPs = value;
}

private RSVP _RSVPs;

Вот почему они помечены как виртуальные для использования в Entity Framework, что позволяет динамически созданным классам переопределять внутренние функции get и set. Если ваши свойства getter / setters для навигации работают для вас в вашем использовании Entity Framework, попробуйте пересмотреть их только на свойства, перекомпилировать и посмотреть, сможет ли Entity Framework функционировать должным образом:

 public virtual ICollection<RSVP> RSVPs;