Organize EDMX Classes

Asked

Viewed 78 times

2

I have a DB First project that uses an EDMX to map the database. The tables have standard columns that exist in all of them and that I could organize and make the code much more generic if it was possible to implement interfaces in it with these properties, but it is not a good practice to change the classes automatically generated by EDMX.

Is there any good practice or standard to improve the organization and reuse of code in the DB First model?

Updating

Seeing that apparently there is no direct solution to this problem, is there perhaps some way then to make a code started with Codefirst change automatically with some change made in the bank? (import the modifications)?

c# .net entity-framework database-first
  • 1

    "...but it is not good practice to change the automatically generated EDMX classes". It depends. If the bank is modified frequently, it is not even. Otherwise, there is no problem. I would like an answer considering the second case?

  • Yes, I would like to. The bank is not often changed, but every time it was changed it would import the classes again and undo what was done. There’s no way around that?

  • So, but my answer will end this import scheme, okay?

  • 1

    "[...] but it is not good practice to change the automatically generated EDMX classes.". It’s not that I’m not a good practice, right. That’s not a good idea, because, as already said, whenever changing the bank these classes will be generated again.

  • Yes. Knowing all these questions, how then I could create a better solution to this problem, since I can’t use Codefirst and the whole project is already based on these imported tables?

  • 1

    Quite interesting your question, I really do not know a solution "elegant" and killer for this case. But searching I came across something similar when trying to implement Metadatatypes in classes generated by DB first. Since these classes are generated as partial, could you not create new partial classes as well and implement your idea? Here’s an example of something similar, see if it helps you find a direction: Link -> http://stackoverflow.com/questions/9071120/defining-data-annotation-using-dbcontext-versus-objectcontext-in-the-database-fi/9073286#9073286

  • Because then, this link is useful to put additional properties and methods to an automatically generated class without losing the modifications, but in my case I need to implement an interface. I will test if it is possible to do this with Metadatatypes here.

  • Is there perhaps some way then to make a code started with Codefirst change automatically with any changes made in the bank? (import the modifications)?

Show 3 more comments

1 answer

0


I found that the solution is simpler than I expected.

//Classe gerada automaticamente pelo EF
public partial class BaseClassPartialTests
{
    public string PropTeste1 { get; set; }
    public string PropTeste2 { get; set; }
    public string PropTeste3 { get; set; }
}

//Como a classe gerada pelo EF é uma Partial Class, 
//basta criar, em outro arquivo, uma outra classe parcial herdando da interface que eu quero.
public partial class BaseClassPartialTests : IBaseProps
{
    public BaseClassPartialTests()
    {
        PropTeste1 = PropTeste2 = PropTeste3 = string.Empty;
    }
}

//Interface para aplicar nas classes.
public interface IBaseProps
{
    string PropTeste1 { get; set; }
    string PropTeste2 { get; set; }
}

The downside is that I will have to create a partial class for each automatically generated EF class, but applying the interface to them will make it possible to make all my access codes much more generic and less repetitive. Including the possibility of creating builders.

Browser other questions tagged c# .net entity-framework database-first

You are not signed in. Login or sign up in order to post.