none
LINQ to SQL, WTF !? RRS feed

  • Question

  •  


    i dont know why microsoft always dont want to do his works completely.

    i want to start my new project based on LINQ-to-SQL , and i don't want to use it's designer !!

    i want to create my classes , put some attribute above its properties and the use it.

     

    after plenty of times that i tried to figure out how should i mention the Association attribute , now i faced to a

    new problem !!

    Linq to SQL need another useless ID column for it's associaton in bussiness layer !!!! ( as i learned , in

    business logic layer , we should not have any information/property/field about database or some other Data layer,

    now microsoft changed it !!! )

    for ex. assume we have to class :

    1. Person

    2. Phone

     

    that every Person have some Phones.

    i should place a PersonID in Phone that i can use attribute class on it ! . do you think is it correct ?

     

    this is just okay, another problem is , as a developer i decided to place a List<Phone> in persone class and do

    not want the reverse relation( Person in Phone class ) .

    but LInq to sql , push me to make the reverse relation too for making a simple association relationship !!

    ( this action cause a loop in my Object class diagram !!! )

     

    and the last and most problem , after all these silly things , the linq to sql , can not set PersonID automaticly

    in phone rows in database !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! i should set it explicitly or do it via Property change

    events !

     

    believe me or not , this is all things happens in linq to sql IF you dont use its designer . if you use its

    designer , the designer make code for all of this things . you can go and see the generated codes .

    but i dont like that my classes be partialed in some files , so i dont want to use the linq designer . but if i

    ommit this , the code that linq designer generated for a class is very very unreadable beacuse of its property

    events and plenty of fileds, methods , events , blah blah blah .. just for doing a simple relationship !!!

    Friday, April 25, 2008 9:34 PM

Answers

  •  EasternBoy wrote:

    i dont know why microsoft always dont want to do his works completely.

     

    I can assure you that here I see many people every day that strive for shipping the best possible products. The key is in the word "shipping". Some day your product needs to be out in the hands of customers so they can take advantages of its features. So, every time we plan for a product we need to decide on which the priority scenarios that we want to enable are and what can be left for v.Next. We cannot work forever in a single iteration of a product to match all customer expectations, which would mean that we never ship and we end up not addressing anybody's expectations Smile


    Now, sorry if this answer is too general. I do understand your pain.

     EasternBoy wrote:

    i want to start my new project based on LINQ-to-SQL , and i don't want to use it's designer !!

    i want to create my classes , put some attribute above its properties and the use it.

     

    after plenty of times that i tried to figure out how should i mention the Association attribute , now i faced to a

    new problem !!

    Linq to SQL need another useless ID column for it's associaton in bussiness layer !!!! ( as i learned , in

    business logic layer , we should not have any information/property/field about database or some other Data layer,

    now microsoft changed it !!! )

    for ex. assume we have to class :

    1. Person

    2. Phone

     

    that every Person have some Phones.

    i should place a PersonID in Phone that i can use attribute class on it ! . do you think is it correct ?

     

    The goal of LINQ to SQL is to provide a relatively straightforward object mapping over your relational model, which is useful in many scenarios. Foreign keys are part of your relational model, and LINQ to SQL doesn't attempt to abstract from them.

     

    If you are looking for more advanced mapping, I would suggest you to take a look at the Entity Framework, which is based in an Entity-Relationship model and actually won't show you a PersonID in the Phone class by default.

     

     EasternBoy wrote:

    this is just okay, another problem is , as a developer i decided to place a List<Phone> in persone class and do

    not want the reverse relation( Person in Phone class ) .

    but LInq to sql , push me to make the reverse relation too for making a simple association relationship !!

    ( this action cause a loop in my Object class diagram !!! )

     

    There are two points here. First of all, while having an unidirectional navigation property may not be supported by the designer, it is supported by the runtime. You can edit your DBML file with a text editor, remove the association on one side, and then regenerate your class with SqlMetal (Thanks Kathy and Josh for helping me confirm this).

     

    On the other side, if you are concerned about cycles in your model because of serialization, you can currently set serialization only to "Unidirectional", which will put the DataMember() attribute on one side, so, at least for WCF serialization the cycle is not an issue.

     

     EasternBoy wrote:

    and the last and most problem , after all these silly things , the linq to sql , can not set PersonID automaticly

    in phone rows in database !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! i should set it explicitly or do it via Property change

    events !

     

    believe me or not , this is all things happens in linq to sql IF you dont use its designer . if you use its

    designer , the designer make code for all of this things . you can go and see the generated codes .

    but i dont like that my classes be partialed in some files , so i dont want to use the linq designer . but if i

    ommit this , the code that linq designer generated for a class is very very unreadable beacuse of its property

    events and plenty of fileds, methods , events , blah blah blah .. just for doing a simple relationship !!!

     

    The generated code is a little complex because it is helping solve a complex (and interesting) problem, which is keeping an object graph synchronized on the fly on arbitrary edits: Relationships need to sync in both directions, and there are also foreign key values that represent the same relationship... There is currently no generally applicable way for a change tracking system to get notified about the changes you make in your graph without the objects in your graph explicitly exposing events or calling methods.

     

    Hope this makes sense to you,

    -Diego

    Saturday, May 10, 2008 1:12 AM

All replies

  •  EasternBoy wrote:

    i dont know why microsoft always dont want to do his works completely.

     

    I can assure you that here I see many people every day that strive for shipping the best possible products. The key is in the word "shipping". Some day your product needs to be out in the hands of customers so they can take advantages of its features. So, every time we plan for a product we need to decide on which the priority scenarios that we want to enable are and what can be left for v.Next. We cannot work forever in a single iteration of a product to match all customer expectations, which would mean that we never ship and we end up not addressing anybody's expectations Smile


    Now, sorry if this answer is too general. I do understand your pain.

     EasternBoy wrote:

    i want to start my new project based on LINQ-to-SQL , and i don't want to use it's designer !!

    i want to create my classes , put some attribute above its properties and the use it.

     

    after plenty of times that i tried to figure out how should i mention the Association attribute , now i faced to a

    new problem !!

    Linq to SQL need another useless ID column for it's associaton in bussiness layer !!!! ( as i learned , in

    business logic layer , we should not have any information/property/field about database or some other Data layer,

    now microsoft changed it !!! )

    for ex. assume we have to class :

    1. Person

    2. Phone

     

    that every Person have some Phones.

    i should place a PersonID in Phone that i can use attribute class on it ! . do you think is it correct ?

     

    The goal of LINQ to SQL is to provide a relatively straightforward object mapping over your relational model, which is useful in many scenarios. Foreign keys are part of your relational model, and LINQ to SQL doesn't attempt to abstract from them.

     

    If you are looking for more advanced mapping, I would suggest you to take a look at the Entity Framework, which is based in an Entity-Relationship model and actually won't show you a PersonID in the Phone class by default.

     

     EasternBoy wrote:

    this is just okay, another problem is , as a developer i decided to place a List<Phone> in persone class and do

    not want the reverse relation( Person in Phone class ) .

    but LInq to sql , push me to make the reverse relation too for making a simple association relationship !!

    ( this action cause a loop in my Object class diagram !!! )

     

    There are two points here. First of all, while having an unidirectional navigation property may not be supported by the designer, it is supported by the runtime. You can edit your DBML file with a text editor, remove the association on one side, and then regenerate your class with SqlMetal (Thanks Kathy and Josh for helping me confirm this).

     

    On the other side, if you are concerned about cycles in your model because of serialization, you can currently set serialization only to "Unidirectional", which will put the DataMember() attribute on one side, so, at least for WCF serialization the cycle is not an issue.

     

     EasternBoy wrote:

    and the last and most problem , after all these silly things , the linq to sql , can not set PersonID automaticly

    in phone rows in database !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! i should set it explicitly or do it via Property change

    events !

     

    believe me or not , this is all things happens in linq to sql IF you dont use its designer . if you use its

    designer , the designer make code for all of this things . you can go and see the generated codes .

    but i dont like that my classes be partialed in some files , so i dont want to use the linq designer . but if i

    ommit this , the code that linq designer generated for a class is very very unreadable beacuse of its property

    events and plenty of fileds, methods , events , blah blah blah .. just for doing a simple relationship !!!

     

    The generated code is a little complex because it is helping solve a complex (and interesting) problem, which is keeping an object graph synchronized on the fly on arbitrary edits: Relationships need to sync in both directions, and there are also foreign key values that represent the same relationship... There is currently no generally applicable way for a change tracking system to get notified about the changes you make in your graph without the objects in your graph explicitly exposing events or calling methods.

     

    Hope this makes sense to you,

    -Diego

    Saturday, May 10, 2008 1:12 AM
  • Diego,

    I've just encountered a similar issue to EasternBoy's. Can you confirm that linq to sql requires the class on the "many" side of an association to have a property/field to contain a foreign key? If so are there any plans to change this in the future, or is that functionality left to linq to entities?


    Just a point about change tracking - I think there are generally applicable ways change tracking systems can get notified, e..g. I believe NHibernate creates proxies of entity classes that can intercept calls to setters. (Of course this requires properties declared virtual.)

    Thanks.
    Keith

    Tuesday, June 24, 2008 4:05 PM
  • Hello Keith,

    Yes, as I think I said before, LINQ to SQL does not try to hide the underlying relational model, and having a foreign key is the way you implement this kind of association in a relation database.

    That said, you can change the access of the property to protected or private.

    Hope this helps,
    Diego

    Tuesday, June 24, 2008 5:04 PM
  • >i want to create my classes , put some attribute above its properties and the use it.

    I wrote this blog for folks wanting to do what you want

    >
    i should place a PersonID in Phone that i can use attribute class on it ! . do you think is it correct ?
    Yes it is an entity. All entities need

    Entities should have identities which persist throughout their lifetime, and are not derived from their state. For example with a person their name is not a good identity, because it might change, though choice or marriage, during their lifetime, so you need an identifier which lasts throughout their life. These tend to be a numeric key or guid.  This is a tenet of domain modeling. Hiding that identity is not really what you want to push for, your unique identifier is part of your domain model. LINQ to SQL's requirements are entirely correct from a domain modelling standpoint.

    Take a look at this article:

    http://codebetter.com/blogs/ian_cooper/archive/2008/03/09/architecting-linq-to-sql-applications-part-7.aspx

    So you don't need the Entity Framework here, as within a domain model your unique identifier is a valid concept.

    >this is just okay, another problem is , as a developer i decided to place a List<Phone> in persone class and do

    >not want the reverse relation( Person in Phone class ) .

    It's fairly normal for associations to be bi-directional


    >and the last and most problem , after all these silly things , the linq to sql , can not set PersonID automaticly

    >in phone rows in database !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! i should set it explicitly or do it via Property change

    >events !

    No you can mark up your identity column to be auto-generated. See the first article I linked too

     


    Friday, July 4, 2008 9:17 AM