views:

92

answers:

2

Ok obviously I am fighting .net here ... and the answer is probably that i am barking up the wrong tree and should just get on with just using the kind of database design i would of 5 years ago.

What I want is to have an abstract object Client and have 2 inherited objects Supplier and Customer.

The relationship between client and both supplier and customer is 1: 0/1

This seems to mean that a solution based on inheritance would work well as it would enable me to write less validation code as well as lever the strongly typed collections.

However out of the box entity framework insists on using unique id's on the client table and refusing to let you have the same id referenced from the Customer and supplier tables.

when you go into the database and edit this id manually to be the same on both inherited objects you then get problems because the collection of clients has an index collision (unsuprisingly).

the result is that I cannot have a client who appears as both a supplier and a customer (I was happy with the idea of 2 seperate objects sharing the same id).

This leads into a design question of how to best model this scenario ... I am at risk of having to do a conditional join and boolean fields for 'isCustomer', 'isSupplier' or a suppliers and customers table that joins to client and write code to maintain the a 0-1 relationship with it.

Someone else must of had this kind of issue? No elegant solutions?

an alternative: I need multiple views of the same object. This means that I cannot simply have an integer value on one field determining which views are allowed. I require using several bool fields to determine what object views are allowed.

Is this possible in EF? Obviously I can create views in the DB, but id rather do this from EF and have it create the SQL. (although i am already defining sp's to set up various keys and constraints in the db, but this means i am getting more and more likley to abandon using EF to generate my schema)

A: 

Put whatever is common to customers and suppliers in client, and only the stuff specific to customers in customer, stuff specific to suppliers in supplier.

3 tables, 3 types of objects.

Beth
Thankyou, this is what i have done, however this will not allow me to have one client who is *both* a supplier and customer.
John Nicholas
oh, I see what you're saying. maybe have a table with all customer and supplier fields?
Beth
yeah that is one option ... but I don't like as I could normalise the supplier and customer fields out into seperate tables - leaving client with supplierId and customerId and enforce a unique key on both columns. (im a pain the ass ;) but thanks)
John Nicholas
+1  A: 

Unfortunately, what you're asking for isn't really possible. .NET doesn't allow for multiple inheritance, so this isn't (and won't be) a feature of EF or any other ORM.

You'll have to remove the inheritance in the EF designer and just allow a normal 1:1* association between the tables.

You'll end up with the database design you're looking for, and your C# syntax will look like:

Client c;

c.Customer.[...]
c.Supplier.[...]
Adam Robinson
idd sadly this is the conclusion i am coming to ... that is the simplest i have come up with so far. At least the ORM manages the 1:0/1. Just shows the old addage of prefering associatino over inheritance once again rules (so far)
John Nicholas