Basic question about object-relational impedance mismatch , a topic with which I have little experience.
Does it really exist? (Certainly, Martin Fowler > and Ted Neward already talked about the problem, but does it really occur in all situations involving objects and relational database?)
If yes, in what situations does it occur? (For example, it is a systems-specific problem where the domain model guides the bank design, not vice versa ?)
What are the limitations of these solutions?
Maybe my answer is vague, but if we analyze, the question was very broad and I have no reputation to comment.
Just look at the situation as follows, the proposal of the ORM's is a lie. It is the same as saying that you will mix water and oil. If you just need a liquid whatsoever the mix is good, but if you need to emphasize either side, you'll have to give up the other.
What I mean is, objects are formed by two things, necessarily: 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? has no way to embed behavior in a database table the same way you do with an object, the two things do not really match.
But it is possible, yes, to extract part of the two things and form very similar data structures that are likely to meet your needs, it is all a matter of judgment. I do not remember going through a situation where "Impedance Difference" was a surprise problem, the problem is yes, we learn to live with it.
Edit:
The discussion in the comments made me think of a possible solution.
At this link: link o Uncle Bob describes how" Tables "are not" Business Objects "but" Data Structures "(or classes without method / functions) of which true business objects use as a resource.
One way to avoid "impedance difference" is to segregate the "relational object" from the business object. Here's 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; }
}
In this way you avoid the temptation to find that the relational object is actually an object and uses it more similarly to a database table.