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, что должно обеспечить небольшой прирост производительности, особенно для больших скомпилированных запросов.