How to generate POCO proxies from an existing database

 

I recently switched to Entity Framework 5. Now, I want to generate the POCO classes from an existing database and also I need both lazy loading and change tracking. So all the scalar properties should be virtual as well as navigation properties.

Adding a new ADO.Net Entity Data Model ends in an .edmx file and some other .cs and .tt files.

Firstly, I wonder why the generated POCO classes by default do not meet the requirements of change tracking proxy, ie scalar properties are not virtual.

Secondly, how can I genrate proxy-enabled poco classes?

PS: I accepted the Slauma's answer as the best and the only answer so far but I don't agree with the first part of it. Here is my argument

Slauma talks about two problems with proxy: restrictions and performance:

  • About the restrictions on the proxy-enabled entities: When the classes are generated in DB First method by Entity Framework, the rules that the classes must follow to enable change-tracking proxies are not that much important becuase they are not restrictive at all. Who really cares whether the navigation collections are IList or HashSet? Talking about the restrictions is sensible only when there are perior designed classes in the application and tables are to be generated from them.

  • Complex properties are not supported in DB first. So we can exclude them from our discussion.

  • About the perfomrance: In the addressed article and also some other experiments I have studied so far the results are not very convincing to reject proxy in favor of snapshot. First, the experiments were done on a large number of entities aka 10,000. It is not improbable that a batch process in your application(not in database) works on large number of entities, however better approaches are assumed such as stored procedure. Second, depending on the type of the application and the needs, we usually deal with few number of entites for example when Repository pattern is impelemented and used; there is no difference between the performance of proxy and snapshot. Interestingly, in the addressed experiment, re-assigning the same value to the properties was the only case when performance of proxy dramatically fails. But who really does this? It is very easy to be careful to avoid repeatedly notifying change tracker. Again, in this case significant problem arrises when large number of entites are dealt with.

    • Firstly, I wonder why the generated POCO classes by default do not meet the requirements of change tracking proxy, ie scalar properties are not virtual.

    Using change tracking proxies is not recommended as the default change tracking strategy. It is explained in more details in this blog post. In essence the main reason to use change tracking proxies - better performance compared to snapshot based change tracking - is not always guaranteed - and sometimes it's even worse - and the list of disadvantages is longer than for snapshot based change tracking.

    In the past the T4 templates that generated POCO entities indeed marked all properties - including scalar properties - as virtual and prepared the entities for proxy based change tracking. For the reasons described in the blog this has been changed for the newer templates, including the DbContext Generator for EF 5, as mentioned in this comment below the blog post linked above. Now, only navigation properties are marked as virtual , but not scalar properties, which allows lazy loading but is not sufficient for change tracking proxies.

    Secondly, how can I generate proxy-enabled poco classes?

    I am not aware of any available T4 template that would do this, but it is quite easy to modify the default template to mark also the scalar properties as virtual :

  • In your project you should have two files with a .tt extension: YourModelContainer.tt and YourModelContainer.Context.tt . Open the YourModelContainer.tt file.

  • In this file you'll find a method called Property : 

    public string Property(EdmProperty edmProperty)
{
    return string.Format(
        CultureInfo.InvariantCulture,
        "{0} {1} {2} {{ {3}get; {4}set; }}",
        Accessibility.ForProperty(edmProperty),
        _typeMapper.GetTypeName(edmProperty.TypeUsage),
        _code.Escape(edmProperty),
        _code.SpaceAfter(Accessibility.ForGetter(edmProperty)),
        _code.SpaceAfter(Accessibility.ForSetter(edmProperty)));
}

    Change the line with... 

            Accessibility.ForProperty(edmProperty),

    ...to... 

            AccessibilityAndVirtual(Accessibility.ForProperty(edmProperty)),

    • That's it.

    Just to mention it, in case you are not familiar with it, but there is a second kind of Database-First approach available, that is Reverse Engineering an existing database to a Code-First model. This approach doesn't use a T4 template at all but creates a Code-First model and a context with Fluent API mapping. It is useful if you want to customize and extend the model classes (you could also add virtual modifiers then manually) and proceed with Code-First workflow (and Code-First Migrations) in future to update and evolve your database schema.

    链接地址: http://www.djcxy.com/p/73666.html

    上一篇: addAction被调用时移除通知？

    下一篇: 如何从现有数据库生成POCO代理