Data Services - Lacking

Question

Hi, All the hipe and stuff about Data Services and only now I discovered that joins, counts, complex types in service operations (also not creating a methods in the service reference for the service operations) are not supported (I am sure there is more). Also in the Entity framework (objectservices side of things), computed columns and entities that only map to stored procedures are also not supported. I have great love for the technology however I have decided not to use them on my projects (specialy data services) until the features above are implemented. I have gotten some fustrated that I was even considering writing my own queryprovider to allow me to expose my entities cross the wire. If anyone, in the off chance, have solutions to the above I would greatly appreciate if you were share them here with me. Regards Dancoe ------ Wanting to change the topic but i cant muahah

Answer 1

Hi,

 

Thanks a lot for the feedback. We are tracking all of these and looking to fix them in our future releases.

 

There are some workarounds to make them work in V1.

• We do allow complex types to be returned from ServiceOperations. Currently, we do not allow complex or entity types to be sent as parameters to service operations. Not sure which one you are talking about.
• About joins, the workaround will be to do the join in service operations and return the result as a complex type. you need to define this complex type in the model, if you are using EF as the underlying provider.
• Same thing about count - you can have an service operation that takes a query/entity set name and you can execute them in the server and return the count.
• About service operations not being generated as methods in the client, the only workaround is to do themselves by hand or use DataContext.Execute method and invoke them directly.

I know the above workarounds are not great/ideal. That's why there are workarounds. As i said, earlier, we are working on bunch of these and you should see them in our future release.

 

Please keep sending feedbacks like these which will help us improve the product.

 

Thanks

Pratik

 

Answer 2

Thanks Pratik.  I have not seen an example of returning complex types and using EF.  Any samples out there?  I tried it once and got no joy, and stopped trying.  I'd like to see a complex type with collections.

 

As far as count goes, there are far more cases where you need a count but limited with a Where clause.  So you need a way to pass a predicate.  I have posted samples of such a method here, but as you say, it is not very clean. 

Answer 3

First lets talk about EF - EF only allows collection of entities or primitives to be returned from function imports. If you are using Astoria with EF as the underlying provider, and you want to expose a service operation which is mapped to a function import in the EF, then you can only return collection of entity/primitives from service operations.

 

But since astoria is more flexible in terms of the returns types from service operations, one can write a service operation which can directly invoke a store procedure or maybe execute a query using EF Data Context (probably a projection query), then consume the results and put them in a complex object and return it.

 

Thanks

Pratik

 

 

 

Answer 4

Well lets see.

The only Complex types you allow to be returned in service operations are complex types that exist in the entity model (which if you remember ALL types there must be mapped to a table on the database).

can you see my problem there?

The work around about joins is fine i have used Service operations to work around this problem.

It is extremely difficult to get the count that way, you would need to parse the whole $filter expression to be able to get the right value.

Not having the methods calls being generated is pain, but like you have said all we have to do is create the method ourselves. I hoping that V2 will implement the method generation.

-----------

@ Pratik last post: But you cant do that the data service only returns types that the model exposes like the EF. So we are stuck with what we send back on a service operation.

dancoe

Answer 5

I agree that some of these things are quite inconvenient and we're looking at fixing them (e.g. use of custom types in addition to types defined in the input model in order to produce custom result-sets). However, some others are just intrinsic to the nature of Data Services.

The Data Services framework is not a gateway to a database and in general if you need something like that then Data Services will just get in the way. The goal of Data Services is to create a resource model out of an input data model, and expose it with a RESTful interface that exposes the uniform interface, such that every unit of data in the underlying model ("entities") become an addressable resource that can be manipulated with the standard verbs.

Often the actual implementation of a RESTful interface includes more sophisticated behaviors than just doing CRUD over the data under the covers, which need to be defined in a way that doesn't break the uniform interface. That's why the Data Services server runtime has hooks for business logic and validation in the form of query/change interceptors and others. We also acknowledge that it's not always possible or maybe practical to model absolutely everything as resources operated with standard verbs, so we included service operations as a escape-hatch.

Things like joins dilute the abstraction we're trying to create. I'm not saying that they are bad or anything (relational databases without them wouldn't be all that useful), it's just that if what's required for a given application scenario is the full query expressiveness of a relational database to be available at the service boundary, then you can simply exchange queries over the wire (and manage the security implications of that). For joins that can be modeled as association traversals, then data services already has support for them.

I guess this is a long way to say that Data Services is not a solution for every problem that involves exposing data to the web. If you want a RESTful interface over a resource model that matches our underlying data model, then it usually works out well and it will save you a lot of work. If you need a custom inteface or direct access to a database, then Data Services is typically not the right tool and other framework components such as WCF's SOAP and REST support do a great job at that.

Pablo Castro
Software Architect
Microsoft Corporation
http://blogs.msdn.com/pablo

---

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 6

Hi pablo

The ado.net data services is not a gateway to a database? I agree but again I think there great danger to use these words, be proud of the technology man it is a really good idea and implementation, I only made the original post because I was on fit of rage when i stumbled on the problem listed above about the entity framework and data service (which is inherited from entity framework) I care about what come of Astoria, it is great tool which has great potential to become even greater.

I know I wont bang about complex types anymore they are coming but we dont know when, I think the failure is of the presentations every single one I have been in I seen nothing about the thing that it doesnt do or the purpose of it as described above, infact you come out of them thinking it can do all of these things even if they were not directly talked about. 

Dont we already exchange queries over the wire? Astoria seems to manage the security implication quite well.

I hope there is still scope to make Ado.Net Data Services a even better tool so it can be the solution to more problems then it currently is.

Regards

Daniel Portella

http://undocnet.blogspot.com/

Answer 7

The Data Services framework is not a gateway to a database and in general if you need something like that then Data Services will just get in the way. The goal of Data Services is to create a resource model out of an input data model, and expose it with a RESTful interface that exposes the uniform interface, such that every unit of data in the underlying model ("entities") become an addressable resource that can be manipulated with the standard verbs.

If that is so Pablo why did you implement an Linq Query provider? If Data service is really just an RESTful interface which you have said it is, then the introduction of Linq and all the rest was not required or wanted really because now Data service is hybrid not really here or there. Where the team will not go either way, just implementing functionalty that will get them brownie points. example: return of the count of available records for your query that is going to be use on paged scenario. (I mean the idea that the count value will be return on the same  result set as the results, somewhere on the metadata or what ever)

The focus seems to me all wrong, May be you have done all the development already, so all the problem we have reported and gripped about are fixed and that is why the team is looking at things like that.

Either way it would be nice besides the design notes (that i think there wont be more of them), you could put the development tasks or issues etc. Like you have in code plex and other project site you can see the task and issues being develop and people can comment on them etc that would have a much better impact and be much more transparent then the "transparent design process".

Regards

Daniel Portella

http://undocnet.blogspot.com/

Answer 8

The hardest thing for me with ADO.NET data services was understanding their real meaning and positioning within the Web services, SOA architectures space. ADO.NET DS, indeed provides just a basic gateway to the database and some querying facilities. If you  take it for that, you won't be disappointed.

It would be great if MS could provide a "decision chart" which guides people into selecting WCF versus ADO.NET DS. This chart should inasmuch as possible expose the implications of the choice as often times the hardest part when using a new technology is avoiding situations where you've invested several months in the technology only to find out that it won't meet your requirements. That is of course a big turnoff and something not good for either MS or the developer working with ADO.NET DS.

The following are just examples which should be on that decision chart:

- If you want to expose helper methods from your EDM via your ADO.NET DS, then that won't work. I have read this should work by manually tweaking the EDMX file, but that is not a practical solution.

- If you want to isolate your client from changes in the underlying data sources, WCF is best: Using ADO.NET DS because of its design, "A gateway to the DB", propagates all changes in the database all the way to the client. This makes it very difficult to have teams working in parallel, some folks in UI, some in Middle Tier as it is non-trivial to correctly mock things in the client or the server, or isolate the service from the DB, and thus the client from the DB. BTW: I understand this is not just an issue related to the design of ADO.NET DS, but the combo ADO.NET DS + EF, and the interplay between the parts, but then again, that is the suite normally used to work with ADO.NET DS.

Hope this helps.

Answer 9

Coffee_fan said:

It would be great if MS could provide a "decision chart" which guides people into selecting WCF versus ADO.NET DS. This chart should inasmuch as possible expose the implications of the choice as often times the hardest part when using a new technology is avoiding situations where you've invested several months in the technology only to find out that it won't meet your requirements. That is of course a big turnoff and something not good for either MS or the developer working with ADO.NET DS.

Thanks, Coffee_fan. I am in total agreement with this request for a decision chart. The decision chart would help clarify when to use each new technology that Microsoft is releasing.

---

Dan Crowell | www.crowsol.com

Answer 10

I totaly follow you on that, a lot of people make choices some times the wrong one because of misunderstanding of the technology.

We could compile what has been said here and make a post, hope get a moderator to make it sticky, then people coming here at least could have some reading material on that matter. 

---

Daniel Portella - http://undocnet.blogspot.com - This posting is provided "AS IS" with no warranties, and confers no rights. If this post is answered your question please mark as the answer and if it is helpful do like wise.