Есть ли какие-либо из этих рекомендаций Entity Framework противоречат друг другу?

Question

Я немного озадачен тем, как подходить к разработке EF при рассмотрении всех этих статей вместе, так как я не могу найти образец, который рассматривает все эти практики в одном месте:

• В следующей статье рекомендуется создать многократно используемый слой кэширования для Azure в хранилище (но он не реализует IDisposable)

• В этой статье рекомендуется, чтобы контекст не использовался повторно для более чем одного HTTP-запроса

• В этой статье рекомендуется инициализировать контекст / репозиторий в конструкторе , он удаляет контекст (репозиторий) путем переопределения контроллера dispose (). Нет заявления об использовании.

• В этом сообщении говорится, что в блоке Using есть проблемы в WCF (ссылка 1) (ссылка 2) (ссылка 3)

• Этот пост демонстрирует возможность использовать IDisposable с использованием блока

• В этом посте показана опция, в которой приложения MVC переопределяют Dispose (), чтобы избавиться от контекста

Вопрос

1. Должен ли я позвонить в Dispose? Где я должен назвать это, чтобы гарантировать правильную жизнь контекста? ... В приложении MVC это, кажется, делается путем переопределения метода удаления контроллера.

2. Как избавиться от кэша Azure, указанного выше? ... Возможно, ObjectCache - единственный объект, о котором я должен беспокоиться.

3. Должен ли я использовать Использование или пользуется ненадежным?

4. Должна ли Microsoft предоставить образец, который решает все эти проблемы? Как будет выглядеть этот образец? (если это не этот ) Большинство примеров, которые я вижу с EF + MVC, имеют различную и противоречивую реализацию. Я не уверен, кому подражать в моем проекте.

Answer 1

Вы сделали ненужные выводы.

Проблема WCF - недостаток дизайна. Microsoft облажалась. Такое бывает иногда.

У меня больше нет ссылки, но я нашел ее при помощи поиска, и вы тоже можете. Во время разработки WCF был момент, когда возник вопрос: «должен ли Dispose () всегда вызывать Close ()». Когда вопрос пришел к Дону Боксу (главный архитектор WCF или что-то подобное), он «не мог придумать ни одной причины, почему бы и нет». Он пропустил причину, почему бы и нет.

Dispose () не должен выдавать исключения. Это из-за следующего:

try
{
    var proxy = null;
    try
    {
        proxy = new ProxyClass();
        throw new Exception1();
    }
    finally
    {
        if (proxy != null) proxy.Dispose(); // What happens if this throws Exception2?
    }
}
catch (Exception ex)
{
    // Which exception do I see in here?
}

Если Dispose() сгенерирует Exception2, то я потеряю Exception1 вместе с трассировкой стека, показывающей, что произошло. Проблема в том, что мистер Бокс не нашел причины, по которой Dispose () не должен просто вызывать Close() для выполнения этой работы. Проблема в том, что с некоторыми привязками Close() фактически должен выполнять некоторую работу. Это имеет место с wsHttpBinding, где происходит обмен сообщениями при Close(). Это означает, что у вас есть реальный шанс Close() вызвать исключение и уничтожить мой стек вызовов.

Answer 2

Основная идея очень проста. Если вы используете IDisposable экземпляры, вам нужно вызвать метод Dispose. Проблема заключается в объеме этих экземпляров и когда вы собираетесь их утилизировать. Лучше избавиться от них, как только закончите с ними.

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

This post says my MVC applications should override Dispose() to get rid of the context

Я никогда не говорил [вам] следует перебрать метод

Answer 3

Начните проверять свои факты - они не правы. В статье об использовании ненадежности не говорится, что это ненадежно. Объекты WCF, находящиеся в неисправном состоянии, не могут быть утилизированы - они уже самостоятельно утилизированы. Вот почему возникает другая ошибка. Это не означает, что использование не вызывает распоряжение. Учитывая, что этот факт неверен, я бы даже не стал комментировать ваши выводы, потому что, очевидно, ваши факты неверны.