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:
- 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.
- 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.
- A designer - yes, a cool tool to do your object models from DB and generate mapping.
- More sproc / function support: strongly typed ways to use stored procs and user defined functions
- Better conflict handling for optimistic concurrency exceptions
- 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
Anonymous
March 16, 2006
Thank you for more sproc support... Fully supporting sproc's is a make or break DLinq feature for me...
Thanks again,
GregAnonymous
March 16, 2006
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.
DineshAnonymous
March 20, 2006
Hi Dinesh,
Here is my list in DESC order :-)
6.
6.
6.
4.
5.
1.
2.
3.Anonymous
March 23, 2006
We hear you Miha, loud and clear :-)Anonymous
March 23, 2006
Fine, fine.. #6
(though personally I'd put #2 within the top 3 -- that enables adoption outside of MSSQL)Anonymous
March 24, 2006
It sounds excellent!
Best regards,
Henrik DahlAnonymous
May 08, 2006
The comment has been removedAnonymous
June 07, 2006
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!Anonymous
June 24, 2006
keep up the good work
lucas!Anonymous
June 28, 2006
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 MuzaAnonymous
July 13, 2006
Good clean designer support.
Make it easy to use so we can show our bosses how productive we are :)Anonymous
July 13, 2006
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.Anonymous
March 23, 2007
"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 :)Anonymous
March 19, 2008
PingBack from http://dinnermoviesblog.info/dineshs-cyberstation-dlinq-whats-cooking-in-the-kitchen/Anonymous
March 30, 2008
PingBack from http://crockpotrecipeblog.info/dineshs-cyberstation-dlinq-whats-cooking-in-the-kitchen/Anonymous
June 05, 2008
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 turnAnonymous
May 26, 2009
PingBack from http://castironbakeware.info/story.php?title=dinesh-s-cyberstation-dlinq-what-s-cooking-in-the-kitchenAnonymous
June 01, 2009
PingBack from http://indoorgrillsrecipes.info/story.php?id=2180