views:

529

answers:

1

We are using ADO.NET Entity for our ASP.NET application.

I have read that the pre-generated views improves the performance. Referred to the blog post,

http://blogs.msdn.com/adonet/archive/2008/06/20/how-to-use-a-t4-template-for-view-generation.aspx, I generated the views. The namespace & classes generated as

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";

I added this to my data layer and test the performance. Couldn't see much improvement. CPU usage always goes to 20-30% utilization (response timing is good) and reduce back to 0% in 500ms - 1 sec. I think the CPU utilization goes high because of view generation every time.

I couldn't understand how the entity framework knows that this is my pre-generated view class for my model eventhough the MyModel.edmx & MyModel.Views.cs matches with filename.

Should I have to update Web.Config or App.Config to map the View class to model somewhere?

Please clarify.

A: 

View generation only helps for "standard" queries (e.g., when you call someObject.RelatedEnd.Load() or MyContext.SomeSetName(). It doesn't help for ad hoc queries with LINQ or ESQL, for obvious reasons. Use CompiledQuery to optimize those.

Craig Stuntz

related questions