Feature requests


Guys, greate work. I hope you will keep it this way. I've just faced the same problems
Some suggestions for the code generator:
  1. Avoid generating DbType, & Storage attributes to further reduce bloat.
  2. Generate private fields without preceding "_" and in camelCase .
  3. Add [Serializable] to the class, so it can be used with binaryFormatter / netdatacontract serializer.
    Not sure about thesee two, but just thoughts:
  4. Keep INotifyPropertyChanged - for perfomance & ease of change tracking on client?
  5. Keep the code that ensures object graph consistency? It's a good thing? This could be done by using some kind of custom collection (possibly list or Collection<T> derivered)
    And the last one, just an idea:
  6. You can still provide lazy loading (when using custom collections) by reimplementing some kind of EntitySet / Ref and setting the source in a constructor. During serialization unloaded properties will return null (using the same trick as in LTS generated code) . I don't get why microsoft didn't do that. And this automatically will give lazy load on deserialized and attached entities.


benjamine wrote May 7, 2008 at 6:57 PM

Thanks a lot, I'll try to answer these points:
  • We're planning to add some type of configuration (e.g an optional xml associated to the .dbml) to allow specifying some of the things you propose (like change tracking), but always opt-in.
  • We need these attributes, AFAIK DbType is required to support the CreateDatabase() method, and we can cut that out. Storage tells the Linq Object Reader to set values directly on the private fields, bypassing the public setters (skipping "is modified" events). This is not only for performance, but also to allow change tracking.
  • This is tecnichally posible, but we don't wan't to force everybody a different syntax than the standard MS Linq Generator, If we decide to implement this, we'll make it configurable, and not the default.
  • If in the O/R Designer you choose Serialization Mode = "Unidirectional" the entities are decorated with [DataContract] and [DataMember] attributes, allowing them to be serialized with the NetDataContractSerializer, I haven't tested binary serialization, but AFAIK System.Linq.Binary (Linq type for TIMESTAMP) isn't Serializable (why!?). If not, we should try to find a workaround.
  • This is another thing we want to be opt-in.
  • To allow change tracking we're going to allow specification of a custom Collection<T> for associations, again, this will be opt-in, because we don't want to tie this Custom Tool to a particular Change Tracking implementation.
  • Like in 5. we're going to allow this by specifying your own Collection class.
    (But we won't recommend this, mainly, because we don't want entities accessing (and knowing how to access!) a database or web service, and in a silent way. We prefer to make every access to the Dal, explicit.)
I'll further discuss this subjects with my teammates, and we'll apreciate any comments!

Kind Regards!

wrote May 7, 2008 at 6:58 PM

wrote Feb 2, 2013 at 5:13 AM