views:

34

answers:

1

After a long thought we found that the best approach for our needs would be to use multiple tables as if it was classes, so we have something like:

tblPerson (pk code)
tblWorker (pk codePerson)
tblPhone (pk code, fk codePerson)
tblAddress (pk code, fk codePerson)

it's almost like classes. It was really necessary because many tables do refer to the "generic person" that could be a regular person or a company, and this could be a client, vendor, system user, and there it goes...

We were creating parts of the GUI using Controls so they could be reused on almost every system and these controls are grouped within multiple projects (DLL).

Question is how to use LINQ to get all this working together. Linq to something like person/phone/address is quite easy and strait-forward. But really no ideia on how to do with, let's say, client. Is there any way to reuse the previous LINQ entities (person/phone/etc) or I'll just have to place them again into the new LINQ DBML file?

Through code I know that I can just get it to work quite fine. Just call the other context and there I can access the record... but what about grids? I do need to bind the grid to the linq entities but they are split. And there is no DIRECT connection between, for example, client and phone numbers or client and addresses. All the relationships the this are made through the PERSON (generic person) entity.

...

It's quite confusing to explain, easier to see.

Anyway, any suggestion?

A: 

Linq to SQL doesn't really cover the more interesting parts of ORM tools. L2S can't do object inheritance and polymorphism the way a more sophisticated ORM, like NHibernate, can. L2S is generally for the simple stuff, where you have a one-to-one relationship between the tables and the classes.

Jarrett Meyer