DLinq: What’s cooking in the kitchen


OK, after hibernating in the winter, I am back on the blog.


Some of you joined us on DLinq chat last week so you already have a sense of what is going on. For others, here is a peek at what we are working on:



  1. Inheritance: table-per-hierarchy: It turns out that this feature is more interesting in the LINQ context than in a traditional ORM sense (e.g. ObjectSpaces). Languages like C# and VB provide you a variety of ways to work with types and they all show up in DLinq queries. Take for example C# operators is, as and typeof.

  2. Provider model: yes, we heard your requests and hope to have something on this front. Right from the beginning, DLinq has been intended for all relational databases, not just Microsoft SQL Server which we covered in the preview. At the same time, given the limited resources of our team, it is unrealistic for us to support a broad range of databases (and their various versions, SKUs etc.). That is why we are working on a provider story that ISVs, database vendors and the community can run with.

  3. A designer – yes, a cool tool to do your object models from DB and generate mapping.

  4. More sproc / function support: strongly typed ways to use stored procs and user defined functions

  5. Better conflict handling for optimistic concurrency exceptions

  6. A story for detached object – this is handy for stateless situations like ASP.NET, web services etc.

Now let’s see which of these can get into the next preview. It is going to be a challenge.


Tell us your thoughts about these features and more things.


 


Comments (18)

  1. gduncan411 says:

    Thank you for more sproc support… Fully supporting sproc’s is a make or break DLinq feature for me…

    Thanks again,

    Greg

  2. Dinesh.Kulkarni says:

    Thanks Greg.

    So which of the following matter to you and which ones don’t?

    – Sprocs with out params

    – Sprocs with multiple result sets

    – Sprocs with return value

    – User-defined scalar functions

    – User-defined table-valued functions (TVFs)

    Of course, if you use sprocs extensively, there is really currently no general way to navigate across relationships.

    Thanks.

    Dinesh

  3. Miha Markic says:

    Hi Dinesh,

    Here is my list in DESC order :-)

    6.

    6.

    6.

    4.

    5.

    1.

    2.

    3.

  4. Dinesh.Kulkarni says:

    We hear you Miha,  loud and clear :-)

  5. Keith Farmer says:

    Fine, fine.. #6

    (though personally I’d put #2 within the top 3 — that enables adoption outside of MSSQL)

  6. Henrik Dahl says:

    It sounds excellent!

    Best regards,

    Henrik Dahl

  7. Justin Spindler says:

    6 is important for me because I would really like to be able to take advantage of the flexible powers of DLINQ while retaining a centralized and remoting/WebService/WCF separated data layer.  I’m not sure how in depth this functionality can go, but I’d love to seamlessly issue DLINQ queries against a remoted datacontext or something similar.

    4 is probably next in line.  Apart from using sprocs to update entities we also often use them to consolidate data for reporting or extensive processes which need to be close to the database for performance reasons.

    Top of the list would just be having a better idea as to when this functionality might be RTM.  My company has a couple of large projects coming up and I think DLINQ would work wonderfully.

  8. Wiebe Tijsma says:

    Hi Dinesh,

    Definitely #2.

    I stumbled upon this page looking for resources on how to create my own Data Model Provider for DLinq.

    I’d like to experiment with creating providers for Exchange data store, or SharePoint lists or Lotus Notes databases, any hints on where to start? Is it already possible?

    Thanks!

  9. lucas says:

    keep up the good work

    lucas!

  10. Jorge Muza says:

    Dinesh,

    #2, #2, #2, Wiebe, do you know gentle.net (O/R Mapper for .net) they have a good data model architecture…. im also interested on implement one myself, Dinesh could you give us some starting points?

    Jorge Muza

  11. Steve says:

    Good clean designer support.

    Make it easy to use so we can show our bosses how productive we are :)

  12. Steve says:

    Let me add:  the biggest obstacles you have:

    1. making it ‘Microsoft speak’ rather than using the language of domain model design concepts.  Not saying you aren’t but you should be very in tune with this to make it in the real world.

    2. ‘we can’t use it – it’s Version 1’.  I hear that alot – it’s *triplely* tough when it’s a CTP…should I like the previews…although the current one broke my intellisense and required me to install VBCrapola on my machine.

    3. Entity 3.0 ?  How does that factor in?  Can this replace tableadapters and datasets and instead make it ‘real objects’?  I do like the dataobject attributes right now – it would be good to see a richer objectdatasource control to help in attaching to the objects.

    4. can we have a concept of Inversion of Control in LINQ?  I like what Active Record and NHibernate provide – although the area that is most needed: dealing with complex designs with legacy databases (it’s easy when coding from scratch) – ie. good visual support for one to one, one to many, many to many relationships, etc… hopefully all with generics.

    5. lastly – if you generate code – please make it clean.  I want stored proc support, but at the same time, I don’t .. in other words – I want to work from the objects not the database.  Repository objects would be good.

  13. Steve says:

    "A story for detached object – this is handy for stateless situations like ASP.NET, web services etc."

    Good, I would be able to use it then  :)

  14. Weddings says:

    OK, after hibernating in the winter, I am back on the blog. Some of you joined us on DLinq chat last week so you already have a sense of what is going on. For others, here is a peek at what we are working on: Inheritance: table-per-hierarchy: It turn