Using interfaces for domain classes

Asked

Viewed 84 times

3

Is it good practice to make use of domain class interfaces? Do I have an advantage in doing so? If so, which one?

Example:

public interface IAuditoria
{
    long AuditoriaID { get; set; }
    string Descricao { get; set; }
    string SistemaOperacional { get; set; }
    string ResolucaoTela { get; set; }
    string ModeloDevice { get; set; }
    string Navegador { get; set; }
    string IPInternet { get; set; }
    string Geolocalizacao { get; set; }
    DateTime DataAuditoria { get; set; }
}

public class Auditoria : Entities.Bases.EntityBase, Entities.Interfaces.IAuditoria
{
    public Auditoria()
    {

    }

    #region Properties

    public long AuditoriaID { get; set; }
    public string Descricao { get; set; }
    public string SistemaOperacional { get; set; }
    public string ResolucaoTela { get; set; }
    public string ModeloDevice { get; set; }
    public string Navegador { get; set; }
    public string IPInternet { get; set; }
    public string Geolocalizacao { get; set; }
    public DateTime DataAuditoria { get; set; }
}
c# asp.net-mvc .net inheritance interface

  • I don’t see much point in using an interface in the domain class, following link that can help you a lot https://answall.com/questions/107524/como-e-quando-usar-interface

2 answers

6


Creating by creating for no reason has no advantage. In everything you do, everything you do, until you put a blank space in the code, you need to find a motivation.

That’s why I always tell people to let this good practice thing go. In practice they serve for people followed cake recipes without thinking about what they are doing.

Can you find a reason?

I can say one: have an abstraction to be able to accept a generic type and the concrete be different in each situation. It is the call Programming for interface and not for implementation, why?.

You need to have that abstraction?

If you don’t need to have that generality, I don’t see why you should.

There’s a case that people say to do even if your domain doesn’t need it, which is the test. Without this it becomes a little more complicated to test other things without being able to change the implementation. It is questionable whether it is worth complicating the design concrete only for facilitate the test.

Still, you’ll need to change the implementation to make a better test?

I keep thinking you don’t need.

It’s not what you do that matters, it’s why you do it.

  • As you said I ended up following good practices, it actually came to me to ask this question here, due to not seeing the need to create all this. But in question I was left with the doubt whether or not this could help me in something future, such as tests, among other things.

1

The advantage of the interface is to use its behaviors, regardless of the type of the object.

Example. 

interface IAnimal{
        void Respira();
}
class Cachorro : IAnimal
{
 void Respira()
 {
 //Respira de um jeito
 }
}

class Gato : IAnimal
{ 
  void Respira()
  {
     //Respira de outro um jeito
  }
}

If you have a list of the type of interface and go through it, even if the objects placed in it are different, you will have the advantage of calling them. Already in a domain class, which only serves to maintain the "design" of the data... you don’t have a clear advantage of it, maybe you do, depending on your interpretation of the problem.

It may be interesting to maintain an organization and possibly help in something forward, but, by mere whim, I can not find a justification. It’s worth a debate.

Browser other questions tagged c# asp.net-mvc .net inheritance interface

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