2

The more I research about Microsoft framework on ODATA I tend to believe that it is not suited for enterprise application. The framework expects all the database to be directly exposed as ViewModel, even for simple operations like Pagination & sorting.

We would be forced to use stasteful mechanism to persist page numbers rendered to the JavaScript client.

Or am I not understanding Microsoft implmentation of OData correctly?

EDIT-1:

Is ODATA V4 a Stateful Architecture? As promoted by Microsoft patterns team. I do not see any easy path of Migration from Asp.Net Web API (REST) to OData (Sounds STATEFUL) Architecture.

EDIT-2: Paging, sorting & grouping is part of incoming request from the client.

Abhijeet
  • 13,562
  • 26
  • 94
  • 175
  • https://stackoverflow.com/questions/2458407/difference-between-odata-and-rest-web-services – David Tansey Sep 15 '17 at 06:22
  • 2
    Wait, isn't paging part of the request sent by the client? Except for the title, this seems like a series of statements from your part, do you really have a question? – Icepickle Sep 15 '17 at 06:27
  • @DavidTansey, thanks Answers are dating back to 2010. – Abhijeet Sep 15 '17 at 06:31
  • @Icepickle, updated to be more explicit. – Abhijeet Sep 15 '17 at 06:34
  • Hi @Abhijeet. I feel I have done a good job at answering your question. Could you award the bounty in the next couple of hours when you are back online? It is always disheartening when the system only awards 1/2 the points after the time out (*even though all the points are deducted from the issuer's account*). Thank you in advance and happy coding. – Igor Sep 25 '17 at 10:32
  • thanks for the inputs @Igor, not sure why I have been getting -ve score for the question, Microsoft guys? :-) – Abhijeet Sep 25 '17 at 10:40
  • @Abhijeet - Thank you! Not sure, I do see 3 + votes but I guess also some negatives. Good luck with everything! – Igor Sep 25 '17 at 10:44

1 Answers1

7

In short the MS Odata server side implementation is not statefull and it can be considered a REST architecture.

We would be forced to use stasteful mechanism to persist page numbers rendered to the JavaScript client

You provide paging information in the request. For example, if you wanted 10 items of page 2 you would take the top 10 and skip 10.

odata-url/?$count=true&$top=10&$skip=10

As you can see the client/caller specifies the paging, there is no need for the server to track state of the client.

Also adding $count=true will return the total number of records based on the passed in filter included in the result set (in the above example there is no filter). This will allow the client to calculate the number of pages there are.

The framework expects all the database to be directly exposed as ViewModel...

Also not true. You can return an IQueryable<T> where T is your type. T does not have to be an EF model. For example,returning the following from a DbContext is acceptable.

public IQueryable<SomeEntity> Get() {
    return dbContext.SomeEntities
        .Where(x => optionalPreFiltereExpression)
        .Select(x => new SomeDTO(){
            Prop1 = x.Prop1,
            Collection1 = x.CollectionOfInterest,
            // etc
        });
}

To further illustrate that point you could also return a hard coded list of objects, although this might not be very likely in production.

public IQueryable<SomeEntity> Get() {
    return new List<SomeDTO>(){
        new SomeDTO(){
            Prop1 = 5,
            Prop2 = "Hi there"
            // etc},
        new SomeDTO(){
            Prop1 = 6,
            Prop2 = "Goodbye"
            // etc}
        }).AsQueryable();
}

There are many resources on all the options for OData. I am not going to include everything here, otherwise I might as well just be creating a 2nd set of documentation.

Igor
  • 60,821
  • 10
  • 100
  • 175
  • 1
    Also one thing to stress its stateless nature: paging from page 1 to 2 can result in seeing a record twice. When f.i. a new record is added to the dataset in the time it took to page from page the user from 1 to 2, assuming that record will be the first one on page 1, the last record of page 1 will be pushed to page 2. – Niels V Sep 22 '17 at 12:17
  • @NielsV - Agreed but if this happens also depends on any filter currently passed (which might exclude the added record) and the passed sort expression. This concept holds true for most any stateless program, a record could be mutated or even deleted where it appears different in the sort or is excluded/included in the filter which alters the expected records displayed in a paging operation. – Igor Sep 22 '17 at 12:20
  • Consider up voting current question ;-) – Abhijeet Nov 02 '17 at 12:53
  • @Igor Could you spare few mins here with your valuable insights: https://stackoverflow.com/questions/47055350/odata-case-in-sensitive-filtering-in-web-api?noredirect=1#comment81062048_47055350 – Abhijeet Nov 02 '17 at 12:54