Perhaps my answer is vague, but if we look at it, the question was too broad and I have no reputation to comment on.
Just you see the situation as follows, the proposal of the Orms is a lie. It is the same thing to say that you will mix water and oil. If you only need a liquid any mixture serves, but if you need to give emphasis on either side, you will have to give up the other.
What I mean is, objects are formed by two things, obligatorily: data and behavior, that is, a class that has no methods or functions, is not an object. It’s just a "Data Structure" or Data Structure.
How would you represent encapsulation in a database table? or inheritance? there is no way to embed behavior in a database table in the same way you do with an object, the two things in fact do not match.
But it is possible yes, to extract part of the two things and form very similar data structures that will probably meet your needs, everything is a matter of judgment. I don’t remember going through any situation where "Impedance Difference" was a surprise problem, the problem exists yes, we learn to live with it.
Edit:
The discussion in the comments made me think of a possible solution.
At this link : http://blog.8thlight.com/uncle-bob/2013/10/01/Dance-You-Imps.html the Uncle Bob describes how "Tables" are not "Business Objects" but "Data Structures" (or classes without method/functions) of which real business objects use as a resource.
One way to avoid "impedance difference" is to segregate the "relational object" from the business object. See an example:
Business object:
public class Carro
{
public abstract string Placa { get; set; }
public bool PlacaEhValida()
{
return this.Placa.Length == 7;
}
}
Relational Object:
public class CarroORM : Carro
{
[ColumnName("plate_number")]
public override string Placa { get; set; }
}
This way you avoid the temptation to think that the relational object is in fact an object and goes on to use it in a more similar way to a database table.
The two articles cited in the question themselves present great answers (really very good answers!) to this question. And they are texts too long and in some moments too opinionated for the OS format. What exactly do you propose we solve here? You can ask a more objective question?
– Caffé
Remembering: "You should ask only practical questions, which admit answers based on real problems you have. Extensive and open questions diminish the usefulness of our website and remove other questions from the homepage." http://answall.com/help/dont-ask
– Caffé
@Caffé I wanted to arrive at a non-opinionated answer about the problem, if that is possible. If this is not possible due to a very wide range of scenarios, I would like a scenario-divided response that covers at least cases considered major or more common. If that’s the case I can rephrase the question.
– Piovezan
@Caffé I would also like, given a scenario and the solution adopted (or the solutions) to solve the impedance problem, to explain in a didactic way its limitations, to give a basis of understanding to the beginner in the theme so as to be able to evaluate, with relative property, a new impedance solution with which they come across (which in most cases will be some form of ORM or non-relational DBMS). Even if the responses vary with individual experiences, the OS brings the advantage of providing the evaluation of the best responses and therefore a north for the beginner.
– Piovezan