Reputation: 2160
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.
Upvotes: 1
Views: 270
Reputation: 7591
methods = behavior and behavior is an aspect of objects, not data. to ComputeArea()
is maintained via traditional OOP principals like interhitance and SOLID design.
mapping the data to the objects comes in twoflavors:
quick code snippet for inheritance
abstract class polygon
{
abstract decimal ComputeArea();
}
class Triangle : Polygon
{
public decimal Base {get;set;}
public decimal Height {get;set;}
public override decimal ComputeArea()
{
return Base * Height / 2;
}
}
class class Square : Polygon
{
public decimal Side {get;set;}
public override decimal ComputeArea()
{
return Side * 4;
}
}
class class Circle : Polygon
{
public decimal Radius {get;set;}
public override decimal ComputeArea()
{
return Math.Square(Math.Pi * Radius);
}
}
Upvotes: 1
Reputation: 15577
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.
Upvotes: 2
Reputation: 16149
You can have them inherit from a base class. It will create the same fields in both tables. If you don't want to duplicate the columns, you can make the primary key of square and triangle the primary key of a polygon object, and then just have square/triangle specific fields on those objects.
Overriding the method can be done quite easily. Just make sure to put the [NotMapped] attribute over it.
EDIT: This applies to using Code-First w/Data Annotations.
Upvotes: 1