> there's no Linq specific discussion area
Try http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=123&SiteID=1
Re your base-class question; you can set the entity-base class in the
dbml (but not the designer) - look at /Database/@EntityBase. I'd leave
data-base fields to the ORM, however... You can do largely the same
(and more) on a class-by-class basis using partial classes.
> is there any way to specify in the designer that the
> parent property (AssociatingClass) should not be generated in the child
> class?
With the example you give, I'm not sure whether parent/child are the
right way around - but try tweaking the "Child Property" to false.
Final thought; ADO.NET Entity Framework may offer more options than
LINQ-to-SQL.
Marc
Richard Collette - 11 Mar 2008 14:31 GMT
EntityBase defines a base class for all generated entities. This is not what
I want to do. The DBML is already generating the proper base class and
derived class types. From the dbml:
<DataContract()> _
Partial Public Class CustomerAddress
Inherits Address
....
What is not functioning, is I have another entity class (PurchaseOrder),
which needs to be associated with a CustomerAddress. If I perform a 1 to 1
association in the designer between the PurchaseOrder and the
CustomerAddress, it doesn't allow me to select the Address (base type)
primary key field (AddressId) to make the association. If I make the 1 to 1
association between PurchaseOrder and Address, I can then select the
AddressId field (PK) however, it generates an Address typed property in the
PurchaseOrder and not a CustomerAddress typed property. What I want to do
is set the type of the generated property to CustomerAddress.
For production use at my company, I think we are definitely going to use the
ADO.Net Entity Framework just on the basis that Linq to SQL doesn't support
multi-table inheritance. Of course, designer gotchas like I am running into
right now could prevent that as well.
For now though, I just finished reading Pro Linq and I am trying to get some
simple examples going, just to get some real experience with queries and such.
With regard to not generating properties (references) to the parent from
children. For example, associations could be created from a Client to an
Address, Purchase Order to an Address, Contact to an Address, Packing Slip to
an Address, etc. You quickly see that the Address class is going to get
cluttered up with properties.
Address.Clients
Address.PuchaseOrders
Address.Contacts
Address.PackingSlips
etc.
I am looking for a way to prevent the designer from creating all these
properties in the address class when I create associations to the Address.
And I do want to use a single Address entity (base) because it definitely
makes address standardization and zip code updates with postal software much
easier since all the addresses are in one place.
> > there's no Linq specific discussion area
> Try http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=123&SiteID=1
[quoted text clipped - 14 lines]
>
> Marc
Marc Gravell - 11 Mar 2008 14:59 GMT
> With regard to not generating properties (references) to the parent from
> children.
Did you try what I suggested? Click on the association and toggle
"Child Property" to false. Address is not actually the child here...
Richard Collette - 11 Mar 2008 16:30 GMT
OK, thank you for the kick in the head. You are right, the parent is the
Address and the child is the PurchaseOrder (the one containing the foreign
key). When I create the association from the Address to the Purchase Order,
I can then disable creation of the PurchaseOrder property in the Address.
Still hoping someone can provide guidance on creating an association to a
derived class.
> > With regard to not generating properties (references) to the parent from
> > children.
>
> Did you try what I suggested? Click on the association and toggle
> "Child Property" to false. Address is not actually the child here...