What I'm missing in LINQ to SQL! Will something be in Beta 2?
Now it is about 2 weeks I’m working on some real world ASP.NET application using LINQ to SQL. I found some features I really miss and I will be glad if there will be something supported in Beta 2 release…
1.)Using common database columns in base class. I really miss this, because normally you always have some columns that are in most tables. With this I can remove more then 1000 lines from my current project, not talking about putting common functionality to base classes. So this currently doesn’t work.
publicabstractclass EntityBase
{
int m_iID = 0;
[Column(IsPrimaryKey =true)]
publicint ID
{// ..Implementation }
}
[Table]
publicclass Address : EntityBase
{
string m_strStreet ="";
string m_strZIP ="";
[Column]
publicstring Street
{// ..Implementation }
[Column]
publicstring ZIP
{// ..Implementation }
}
[Table]
publicclass Person : EntityBase
{
string m_strFirstName ="";
string m_strLastName ="";
[Column]
publicstring FirstName
{// ..Implementation }
[Column]
publicstring LastName
{// ..Implementation }
}
2. EntityRef
int m_iAccountID = 0;
EntityRef<AccountBO> m_oAccount =new EntityRef<AccountBO>();
[Column]
publicint AccountID
{// ..Implementation }
[Association(Storage ="m_oAccount", ThisKey ="AccountID")]
public AccountBO Account
{// ..Implementation }
Currently you need to define two fields for using references. This way you have more code, it is not the same pattern as used with EntitySet and it is also very misleading because you are never sure what will be written to database, because there are two variables for the same thing. I think that there should be only one EntityRef field, but you can then define two properties working on this object. Something like this:
EntityRef<int, AccountBO> m_oAccount =new EntityRef< int, AccountBO>();// int is the type of ReferenceID
publicint AccountID
{
get {return m_ oAccount.GetID(); }
set { m_ oAccount.SetID(value); }
}
[Association(Storage ="m_oAccount", ThisKey ="AccountID")]
public AccountBO Account
{
get {return m_oAccount.Entity; }
set { m_oAccount.Entity =value; }
}
Also GetID does not require retriving Account object, because it was already loaded with owner object.
3. Retrive, Update, Create attributes in [Column] – to tell with which SQL operation field is written to database (or better not written)
Sometimes you need that some fields are only written to database when object is created but not with update, or maybe you don’t need to retrieve some field. etc..
4. Similar to point 3, but for EntityRef and EntitySet in [Association]. Most object when there are referenced don’t need to be updated in database when SubmitChanges is called on the owner, so it will be very good to be able to tell in [Association] attribute to never update referenced object. On EntitySet this is not so common because most collections are owned, but still it is good to have this option.
5. I also miss events such as OnRetrived, OnBeforeUpdate, OnAfterUpdate, OnBeforCreated etc., with this you can handle a lot of situation in very elegant way. For example a lot of Web applications have some kinds of Accounts and Account is part of most tables. You can put current account in TLS and then in OnBeforCreated just set account from TLS. If point 1.) is supported this can be in only one place and all object that have Account field should only derive from some AccountObject.
6. Many to many releations
This is what I really miss in current LINQ to SQL implementation. All this can be implemented with current release but it is requiring much more code and object design is far from perfect.
Any comments…
Best regards
Edvin
