ADO.NET Entity Framework - Предварительная генерация представлений -

Question

Мы используем ADO.NET Entity для нашего приложения ASP.NET.

Я читал, что предварительно сгенерированные представления улучшают производительность. Ссылка на пост в блоге,

http://blogs.msdn.com/adonet/archive/2008/06/20/how-to-use-a-t4-template-for-view-generation.aspx, я генерировал представления. Пространство имен и классы, сгенерированные как

namespace Edm_EntityMappingGeneratedViews
{


    /// <Summary>
    /// The type contains views for EntitySets and AssociationSets that were generated at design time.
    /// </Summary>
    public sealed class ViewsForBaseEntitySets4D4A6E0AA7AF6B2298FABB4F22235831 : System.Data.Mapping.EntityViewContainer
    {

        /// <Summary>
        /// The constructor stores the views for the extents and also the hash values generated based on the metadata and mapping closure and views
        /// </Summary>
        public ViewsForBaseEntitySets4D4A6E0AA7AF6B2298FABB4F22235831()
        {
            this.EdmEntityContainerName = "JSEntities";

Я добавил это в свой слой данных и проверил производительность. Не мог видеть много улучшений. Загрузка ЦП всегда идет на 20-30% (время отклика хорошее) и уменьшается до 0% через 500 мсек - 1 с. Я думаю, что загрузка процессора идет высоко из-за генерации представления каждый раз.

Я не мог понять, как платформа сущностей знает, что это мой предварительно сгенерированный класс представления для события модели, хотя MyModel.edmx & MyModel.Views.cs совпадает с именем файла.

Должен ли я обновить Web.Config или App.Config, чтобы сопоставить класс View с моделью где-нибудь?

Просьба уточнить.

Answer 1

Я удивлялся тому же и занимался копанием.

Насколько я могу судить, сгенерированный файл класса содержит атрибут уровня сборки, EntityViewGenerationAttribute, который определяет тип класса, который содержит предварительно скомпилированное представление. Тогда, и здесь я делаю только догадки, во время компиляции класс должен быть загружен с помощью отражения и каким-то образом связан с запросами, которые определяет представление. Возможно, в кеше ESQL, что имело бы определенный смысл.

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