Question

Im using the EF Power Tools to Reverse Engineer an existing Database. This is fine. Under the EDMX Database-1st Route I would create partial classes for any overrides like Data Annotations, for e.g. here, LedgerPeriod being the original EntityObject:

[MetadataType(typeof(LedgerPeriodMetaData))]
public partial class LedgerPeriod
{
    public class LedgerPeriodMetaData
    {

        [Required(ErrorMessage = "Period Start Date Required")]
        [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:dd/MM/yyyy}")]
        [DataType(DataType.Date)]
        public object PeriodDateFrom { get; set; }

        [Required(ErrorMessage = "Period End Date Required")]
        [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:dd/MM/yyyy}")]
        [DataType(DataType.Date)]
        public object PeriodDateTo { get; set; }

    }
}

This is fine. Now do I use the same approach for Code First Reverse Engineer or are there any custom settings whereby if you have to run the power tools multiple times, because say I added a new Table to the Database, it wouldn’t overwrite any changes to the existing Models created previously.

This would ultimately mean I can make changes to the actual model classes themselves, instead of creating partial classes.

Reference to the EF Powertools can be found here:

http://blogs.msdn.com/b/adonet/archive/2012/04/09/ef-power-tools-beta-2-available.aspx

Answer 1

Code First does not officially support the reverse engineering scenario, that’s why it’s called Code First. The power tools are nice, but as you say, they will overwrite things. EF Code First is designed so that you make your changes to the models themselves, not partials and metadata (though you can still use those if you want).

What you could do is use the Customize Reverse Engineer Templates feature of EF Power Tools, then modify the T4 templates to add partial declarations to the generated classes, or you could add code to test for specific entities and modify those as you want.

However, in reality, you shouldn’t need to do this. It’s considered bad design to pass your entities to your Views, and that would be the only reason to add those attributes to the models. On top of that, you’re forcing your views to have the same requirements as your data model, which is also a bad choice.

You should instead be using dedicated view models with your views, and place your data attributes on your view models.