Question

I’ve done a lot of ADO.NET EF programming, but never one where one of the objects/tables inherits from another object/table.

If I have an existing database with three tables (square, triangle, polygon) and add an ADO.NET model to give me Linq access to these tables, how do I establish that the square and triangle objects derive from polygon?

Is there a requirement in the schema where columns in the parent table exist in the columns of the child classes?

And then what if I want to override a method like ComputeArea()? Would I use an extension method or is there a better way?

My underlying question is how/where/if object oriented programming brings value to ORM, but I realize value/subjective questions are discouraged on stackoverflow.

Answer 1

How do I establish that the square and triangle objects derive from
polygon?

You better give a look to this:

Implementing Table Inheritance in SQL Server

And then what if I want to override a method like ComputeArea()? Would
I use an extension method or is there a better way?

Extensions methods should do the trick, better have your entities acting like Value Objects.

My underlying question is how/where/if object oriented programming
brings value to ORM, but I realize value/subjective questions are
discouraged on stackoverflow.

That’s precisely its reason of existence (of ORM) that’s what they’re called object relational mapping. So it do bring value: Cleaner code, easy to write, easy to refactor.

Now, that being said, one disadvantage IMHO is that when users don’t have any kind of experience with the underlying storage technique, usage of ORM tools can not be as performant as should be, not necessarily because the technology but for the way you use it (as for the way to use joins from object oriented vs. relational world) or things like what you’re trying to do, that’s it, inheritance. Those things are pretty straightforward on OO world but not necessary on relational databases.